Introducing EMET v3

Yep, it was outdated. I couldn't find a way to download the latest version manually, because apparently one has to register first, to be able to download Skype from the official website. But, I used the built-in updater, and it downloaded a new version - I don't recall the version number. I reenabled EAF, but it still crashes. Just in case, could you mention what's your version number? And, do you happen to known a direct download link to download the latest version available? I found one at some website, but it actually downloaded an older version than the one that was already installed.


Thanks

 

I don't think 'badly written' would be an accurate description.

I have never dissassembled the dropbox executable so I don't know what the issues are there. But I have looked at the Skype incompatibility in-depth. It really doesn't even matter if I have dissassembled the dropbox executable or not. Just by knowing how EAF works gives me insight on what causes incompatibilities.

Essentially in laymen terms... when an application accesses the export table and attempts to find function addresses in ntdll.dll and kernel32.dll... EMET has set some hardware breakpoints to detect access to this area of the EAT (export table). When EMET detects access it essentially checks the stack pointer to see where/what address is attempting to resolve exports. Then it calls VirtualQuery to ensure that the address attempting to resolve exports is of type MEM_IMAGE. In other words... it makes sure that the calls are coming from a DLL,EXE or other executable PE image.

Typically injected shell code would be of MEM_PRIVATE type memory and most probably PAGE_READWRITE protection.

In other words... any dynamically allocated memory of type PAGE_EXECUTE, PAGE_EXECUTE_READ,PAGE_EXECUTE_READWRITE or even PAGE_EXECUTE_WRITECOPY that attempts to resolve ntdll.dll or kernel32.dll exports will cause EMET to invoke an EAF mitigation.

This would potentially include Javascript,Python,Lua, Ruby or any other scripting language that is dynamically allocating memory and executing native instructions that access the export table. If the interpreted code attempts to resolve exports from ntdll.dll and kernel32.dll it will be flagged by EMET as an EAF attempt.

Earlier versions of Chrome,Skype were also incompatible with EAF. The reason both of these were incompatible was because they implemented their own EAT resolver from an area of memory that was not MEM_IMAGE.

It would not be appropriate to say that they were badly written.

Best Wishes,
-MessageBoxA

 

Great explanation.

I think EAF is the *last* one to say that the program was "written badly" for. It's not common, it's not that amazing, and there's ways to break it through normal/ typical programming.

edit: ACtually, HeapSpray would be the last one.

 

My non-Skype VoIP client doesn't like EAF either. Perhaps it is best left unchecked.

http://www.skype.com/go/getskype-msi

 

Thank you for the write-up MessageBoxA, but it wasn't really in laymen's terms. I'm still foggy on exactly what sort of programming would cause EMET to cosh the program. What do you mean by

Do you mean having pointers to functions that then invoke ntdll or kernel32 functions? Can you give an example of the sort of code that would draw down EMET's ire?

 

v5.10.0.115
Yes, it's dumb that you need to log in to download the client.

 

Bad mostly. You shouldn't care, just be aware of it.
Mrk

 

Didn't we just establish that it isn't about "bad" code only incompatible code? There are valid reasons for EAF not working.

I think with DEP/ASLR there are fewer valid reasons.

 

I apologize for that. It is somewhat difficult to explain technical things in laymen terms. However I will try to explain EAF again... beginning from when an application is launched.

1.) User launches an application named Application.EXE.

2.) The Application.EXE file is mapped into memory by the operating system and the memory is marked as type MEM_IMAGE. Then ntdll,kernel32 is mapped into the applications address space. Then the libraries listed in the AppInit registry key are mapped into the applications address space. Then all DLL dependencies are resolved and many more DLL are mapped into the applications address space. All of the memory consumed by these PE files are marked as type MEM_IMAGE. The EAF mitigation trusts instructions executing from these areas of memory.

Now here is what will trigger EAF:

1.) An application calls VirtualAlloc,VirtualAllocEx and allocates some memory. The operating system *automatically* and permanently marks all allocated memory as MEM_PRIVATE if it is not shared. If the memory is shared for IPC it becomes marked as MEM_MAPPED.
2.) The application copies some instructions into this allocated memory and calls VirtualProtect/VirtualProtectEx to mark the memory as PAGE_EXECUTE or PAGE_EXECUTE_READ or PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY.
3.) The instructions that were copied into this allocated space are executed and attempts to resolve ntdll or kernel32 functions through the export address table. This triggers EAF.


[EAF Enhanced Laymen Terms]

TRUST: The EMET EAF implementation trusts memory that contains executable instructions... IF the memory is located in Application.EXE or one of its DLLs. (Any memory that is marked MEM_IMAGE is trusted)

UNTRUSTED: The EMET EAF implementation does NOT trust executable memory that is not inside an EXE or DLL or other type of PE image. (Any memory that is NOT marked MEM_IMAGE is untrusted)

Hope that is easy to understand. Not sure if I will be able to make it more simple. These technical terminologies/details are mostly for software engineers and security researchers. All the end-users need to know is that there are people out there... researching for a safer computing model.

Best Wishes,
-MessageBoxA

P.S.
Yes, there currently are debatable valid reasons to write code that will trigger EAF. Many PE packers/protectors use this technique to make reverse engineering an application a little more difficult.

 

Ah, I see... thank you very much. That's still mostly beyond my level (and I have essentially no understanding of the Win32 API) but you've given me a vague idea of what's going on.

BTW

The executable image for Skype was actually packed, last I checked. Maybe that had something to do with it?

 

I just tried to download Skype and it appears they've removed this requirement, finally.

 

Thanks. From what I could see, the version installed by the updater was 5.5.0.117, if my memory isn't failing me.

I'll download using the link that user Pinga provided, and will report the results later on.

 

Does anybody here have the standard path for EMET 3 logs for a W7 PC?

 

OK. The latest version I downloaded was 5.10.32.115, and EAF still crashes Skype.

 

You guys must find this as frustrating as I did Dropbox which EAF crashes.

I must remember not to "blame" the messenger EMET.

All I did was disable EAF for dropbox/skype leaving the other mitigations in place.

The vendors/coders should fix their code.

 

If you have the notifier enabled, then the logs should be in Event Viewer (eventvwr.msc). You need to run it with administrator privileges.

 

Is this with EMET 2 or 3?

 

Elapsed, do you have Skype start at startup?

 

Nope.

 

Windows 8?

 

Like my signature states, yes (unless there's an EMET for Linux ). I doubt there would be separate windows 7 and 8 versions this early.

 

It's version 3.

 

No but I just wanted tobe sure since I have Windows 8 and I can check later to be sure that Skype is crashing.

I don't think that there's a separate version it's probably just that EAF doesn't work on Windows 8 or some such thing.

 

Good idea

 

Skype + EAF + Windows 8 = Works fine.

So either EAF isn't working on Windows 8 or there's a separate Windows 8 version.

I wouldn't be surprised at the second one as I think EAF is built into 8 but I can't remember.