Why Chicks Dig IE8
Posted by Mark Dowd on March 25, 2009 at 6:49 PM EDT.
Last year, Alex Sotirov and myself gave a presentation at BlackHat USA entitled "Impressing Girls With Memory Protection Bypasses" (slides here). While the title is a bit of a joke, the content of our speech was not. We presented some pretty serious weaknesses in the memory protection mechanisms present in Vista - specifically in the context of the Web browser. One of the primary techniques we presented involved utilizing Microsoft's .NET controls. Simply put, we demonstrated that it was possible to embed a specifically crafted control into a web page that would be loaded in the browser at a static (known) location in memory, and with any access permissions you chose. This is quite signicant because it simultaneously could bypass two of the primary memory protection features that Vista has in place:- Address Space Layout Randomization (ASLR) - This technology makes it difficult for attackers to successully exploit memory corruption, as it (theoretically) randomizes the way objects are laid out in memory. Our technique bypassed this protection by loading our .NET control at a specific address.
- Data Execution Prevention (DEP) - This technology utilizes processor protection features to ensure that regions of memory with data in it cannot be executed, which is often needed when exploiting a memory corruption flaw. Our technique rendered DEP ineffective since we were able to set arbitrary memory protections inside our .NET control.
Well, it's been a while, but Microsoft has addressed this issue completely with the official release of Internet Explorer 8 - their latest attempt at a browser. Basically, the fix is simple: Loading .NET controls has been associated with a special privilege that users can enable or disable - and in the default configuration for the"Internet Zone" (the Medium-High setting), .NET controls have been disabled. The change is evident in the urlmon.dll located in the Windows\system32\ directory. Specifically, the CTransaction::LoadMimeFilter() function has the new check:
The code above is testing what "Asynchronous Protocol Handler" object is required to handle the incoming content. In the case of a .NET control, the following code is executed:
Here, the ProcessUrlActionEx2() function checks the newly added permission (the newly added permission is 0x2005 as can be seen in the assembly dump). Internally, ProcessUrlActionEx2() examines the permissions for the Internet Zone (first via a cache, and if not there then the registry), and if it is disabled, the loading will not proceed.
So, the net effect (no pun intended) of this change is that by default, our technique will no longer work in its current form against IE8 browsers in their default configuration. There are also a number of other security enhancements in IE8. Most noteably, the browser now runs in "Protected Mode". Essentially, this means that the browsing process runs in a sandbox of sorts with a restricted set of privileges. (Internally, this is implemented by utilizing Vista's "Low Integrity" mode and communicating to a broker process via an out of process COM server. But, that is the topic of another post.) Furthermore, DEP has been enabled in IE8, which is a big change from IE7. This means that IE8 now fully reaps the benefits of the Vista memory protections. Hacking it is going to be hard! .. Probably!
