Internet Explorer 9 Security Part 1: Enhanced Memory Protections
Internet Explorer offers layered defenses to protect against and mitigate each of three major classes of threats that browser users face when surfing the sometimes-hostile Web:
- Technological attacks designed to exploit the browser or operating system
- Web attacks designed to exploit vulnerabilities in Web sites
- Social engineering attacks against the user’s trust
Today’s post covers how browsers’ memory protections mitigate threats in the first class.
Preventing Reliable Exploitation
The goal of these memory protection features is helping prevent reliable exploitation of a memory-related vulnerability. Each technology in the “alphabet soup” of acronyms below is a way to securely terminate the browser tab before malicious code can run. Internet Explorer 9 utilizes the latest memory protection technologies to help prevent an attacker’s code from running if a memory-related vulnerability is discovered in the browser or one of its add-ons:
DEP/NX (Data Execution Prevention / No eXecute) is enabled by default in Internet Explorer 8 and 9 and it is the foundation of memory protection in the browser. DEP/NX works with your system’s processor to distinguish between code and data, helping to prevent execution of data placed into memory by an attacker. If the processor determines that it has been directed to execute a block of memory lacking the proper marking, it will securely terminate the process before executing the specified instructions.
ASLR (Address Space Layout Randomization) is a defense that helps ensure that the memory space of a process is laid out in an unpredictable manner. ASLR helps ensure that an attacker cannot easily bypass DEP/NX protections using a trick called “Return Oriented Programming” in which the attacker simply sets up the attack and jumps to existing code locations, abusing functions which are a part of the browser and operating system. For instance, a common trick is to attempt to jump to the VirtualProtect function which allows memory to be marked as “code” rather than data—if successful, this effectively bypasses DEP/NX. By ensuring that VirtualProtect and other functions are at unpredictable locations, exploit code will generally crash with an Access Violation instead of running successfully.
In IE9, we’ve improved our memory layout randomization to help eliminate predictable memory mappings. However, ASLR is enabled on a per-DLL basis, and some older browser add-ons are not properly opted in to the mitigation. You can use the Process Explorer tool from SysInternals to examine the loaded DLLs in a process to determine whether DEP/NX protection is successfully applied to each. For instance, in the following screenshot, you’ll see that all of the DLLs loaded by the Internet Explorer tab process have ASLR enabled except one ActiveX control which is missing the protection. If that DLL exposes any code segments useful to an attacker, the lack of ASLR randomization could provide a toehold into bypassing memory protections.
Note: Enthusiasts can force ASLR to be applied to all DLLs in the process using EMET (Enhanced Mitigation Experience Toolkit), a security tool provided by the Microsoft Security Research and Defense team to prototype cutting-edge security mitigations. Forcing ASLR onto DLLs which are not expecting it may introduce compatibility problems, however, so keep that in mind if you try out this tool.
SafeSEH (Safe Structured Exception Handling) is a compiler option which helps prevent the injection of malicious structured exception handlers into an exception handling chain. All 64bit code and all of Internet Explorer’s code is compiled with the SafeSEH flag. However, like ASLR, this mitigation is enabled on a per-DLL basis, and hence it requires that add-ons be compiled with the flag in order to ensure comprehensive protection.
This limitation of SafeSEH is mitigated in Internet Explorer 9 when running on Windows 7. IE9 opts-in to SEHOP (Structured Exception Handler Overwrite Protection) a new feature which is enabled on a per-process basis and hence does not require opt-in by individual DLLs. SEHOP works by validating the integrity of the exception handling chain before dispatching exceptions. This helps ensure that structured exception handling cannot be used as an exploit vector, even when running outdated browser add-ons that have not been recompiled to take advantage of SafeSEH.
Lastly, Internet Explorer 9 is compiled with the new C++ compiler provided with Visual Studio 2010. This compiler includes a feature known as Enhanced GS aka Stack Buffer Overrun Detection, which helps prevent stack buffer overruns by detecting stack corruption and avoiding execution if such corruption is encountered. In the latest compiler, the existing GS feature was enhanced to block a broader range of attacks, and it utilizes better heuristics to determine which functions need protection. This enhancement helps minimize the performance impact and maximize protection for Internet Explorer.
Learn More
Software developers can learn more about Internet Explorer’s defenses, including how to use these techniques to improve the security of their own products, by reading the Windows ISV Software Security Defenses whitepaper on MSDN.
Thanks for your help securing the Web.
—Eric Lawrence, Senior Program Manager, Internet Explorer
Comments
Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Google talking about security is even more hilarious, Ryan, because they mean security from everyone but themselves. Go ahead and trust the same guys who stold all those email addresses and passwords with their streetview car with all your secure web transactions. Great idea.Anonymous
March 07, 2011
And apparently you missed the news about how the Android app store is riddled with malware. Where've you been the last week, Ryan? Google HQ?Anonymous
March 07, 2011
I'm truly not trying to be negative though I remember seeing this posted two days ago... www.hardocp.com/.../microsoft_won96t_patch_internet_explorer_before_contest My priority list... 1.) Fix security bugs/vulnerabilities before all-else. 2.) Fix regular bugs in features if live. 3.) Fix regular bugs in features not yet live. 4.) Add new features. Unless I'm missing something this is been my priority hierarchy and it's served me well. I ask, why not prove your dedication to security by ensuring IE can withstand something like the Pwn2Own event?Anonymous
March 07, 2011
If you can apply this much security to the browser - can you give the rest of the dev team a kick to fix things like .innerHTML?Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Wasn't there an ASLR bypassing techniques using the Javascript PRNG?Anonymous
March 07, 2011
Haven't had security issues - I don't install stuff by Google, Adobe, Apple, Oracle (except in a VM). If Microsoft couldn't write secure code by default without making it first priority, what's the chances that those other guys write secure code when security isn't their priority (it's innovation like you say)? As you can see that Google plugin doesn't even have ASLR enabled and that's old feature. Now if someone wants to innovate, make it so that I can install the buggy stuff by those 4 companies and have no impact on attack surface for the host os or my files & other applications. To start with, why should installing app require admin priv? Non-system apps like a browser should not modify system settings. I can install & run DosBox without admin and install games that used to require the whole cpu for themselves. Once apps don't get admin rights at any point, you can next ensure that any exploit in any app will stay within that app. If I can install apps that install system drivers inside a guest OS in Vmware without compromising host, this should be possible without the vmware by total application virtualization built into Windows which depends on what the app wants to install, if it wants to install a driver then virtualize the parts of machine that the driver needs to talk to.Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
@jun That would be very nice, I'm always having to disable programs that think I want to run some nonsense process in the background all day long and they usually re-enable the process each time they get updated glares at google updateAnonymous
March 07, 2011
Ryan, here is another fresh off the press Google security issue: "Researcher finds serious Android Web Market bug" news.cnet.com/8301-27080_3-20040246-245.htmlAnonymous
March 07, 2011
Hey, I just opened Process Explorer (v14.01) to try this out and under the ASLR column it either is blank or says "n/a," nowhere does it say "ASLR" as in this post's screenshot. Am I using a different version than Eric Lawrence is? Also, in my version I'm assuming that a blank entry means ASLR is enabled, and "n/a" means it isn't? I'm confused.Anonymous
March 07, 2011
today, after launching my IE9rc, i noticed all cookies cleared...
- i did not clear the cookies
- i had properly shut down my pc it is really annoying to login to 20+ sites again...
Anonymous
March 07, 2011
@jun, the kernel mode of a modern OS, which is an opinionated software, has number of services running without the user interaction. You think that you own the OS, but it is actually the making its own decisions while setting priorities. But I am sure you are not suggesting MS to make their windowsOS realtime! The threats associated to Nxbit are mandatory to address these days..not only By MS In MS Windows and/or MS IE but for every operating system and application developer. So your claims aboutcftmon to become a user-mode serviceandGoogle apps are secured because they r build that (unsecured) wayare falsified. MS IE is actually known to be most secured web browsers. The level of security they provide in browser is yet to be seen in any other web browser. So, when it comes to industrial scale, all that matters in IT is security. The more secure is your system, the more people would love it. Other argument about UI freezing is true about IE. ….and hey, don’t read too much!Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Who cares about security if IE9 render incorrectly css3 border radius in field set, don’t have css3 multi-columns and don’t have many other css3 properties ? I am developing a social network site that will render ugly on ie9 because of lack of support these features. My users, well, they will use other browser if they want to see a better page... And some parts of my site (games) will not be available to ie9 users because lack of support to webgl, and if the users want to play they need to use other browser that ie9. All browsers have security flaws and all browsers manufactures fix and improve security as possible. But the medium user doesn’t think about this. They think that they can see all sites rendered ok and fast.Anonymous
March 07, 2011
Disable COM first, Discard C++ then.Anonymous
March 07, 2011
Also, Who cares for security if all times that I browse a site with ie9 and upload a file in a page with [input type=file multiple] in ie9 i can only upload one file. The users will use other brwoser than ie9 when they are bored to upload 50 photo to ther album because with ie9 they need to select 50 times the files and with other browser they will select all files one time only.Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
I see. So, in a nutshell, Microsoft is carrying out SDL procedures in Internet Explorer 9. Well, I took that for granted...Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Hmm it seems like I cannot post on this blog using IE9 if I have active X filtering enabled. It is not even tracking protection it is ActiveX filteringAnonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Stilgar I agree with you about html5 form input atributes, including in my previous post I claim about input file multiple. Also You can test all browsers in miketaylr.com/.../input-type-attr.html and see that only ie9 dont have any support to it. all other browser have some support. The criteria I claim to IE team adopt is: If all major browsers (Firefiox, Crhome, Safari and Opera) support one draft, it is a de facto standart and IE need to support it too.Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
i am very not like ie9's gui，simple != easy to use，in fact it is more hard to use，ie8's gui is good，ie9's engine and speed is good，ie8's gui+ie9's engine is very good.Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
@a web developer, those frowny faces do not appear in IE9 providing you turn on tracking protection. It looks very neat that way. win-win for MS !!Anonymous
March 08, 2011
The comment has been removedAnonymous
March 08, 2011
The comment has been removedAnonymous
March 08, 2011
The comment has been removedAnonymous
March 08, 2011
Irony the problem with ie6 is bad implementatio of css (bugs) and lack of vendor prefix. If ie 6 have service packs that fix their bugs and if css in these days have vendor prefix them there are no problem. But today there are vendor prefix. No excuse to implement these drafts. Other browser already implementedAnonymous
March 08, 2011
The comment has been removedAnonymous
March 08, 2011
The comment has been removedAnonymous
March 08, 2011
@John: Yes, it appears that the very latest builds of Process Explorer regressed the display of the ASLR column for the per-module view. It worked properly in older builds, so I'm not sure what went wrong. This regression was first noted on the SysInternals forums in Dec 2010. @Stilgar: Yes, AX Filtering breaks posting comments on the blog in the current version of the blog software; we've filed a bug on the bad pattern that the site is using, and we'll be writing a blog post on exactly what's wrong with the site (preferring ActiveX over native methods) in the next few weeks. @Fleet Command: Indeed, a fair point, although many folks don't follow the SDL closely and have found this information interesting. @Andrew: ASLR is, in fact, a critical feature to mitigate ROP attacks, and that's why you're starting to see its increasingly broad adoption by modern operating systems (e.g. WinVista, latest Mac OS, etc). ASLR on its own isn't of use, of course, you need to couple it with DEP/NX or the bad guy need not use ROP at all. I'm not sure what you were looking at in OllyDbg, but the memory layouts in XP vs. Win7 are significantly different, and change in Win7 on every boot. Also, please keep in mind that IE8+ already run individual tabs in different processes thanks to a feature called "Loosely coupled IE." @jun: I'm not sure what feature you're asking about. IE has many features to control ActiveX, including ActiveX Opt-in, Per-Site ActiveX, and new to IE9, ActiveX Filtering.Anonymous
March 08, 2011
Security on IE is the good. Please to not change it at all. Is very very strong.Anonymous
March 08, 2011
@EricLaw thank you. I've been posting comments with Firefox since IE9 RC not knowing what went wrong. I reasoned you may be referencing JS library from an external resource and checked for tracking protection but it did not occur to me that the ActiveX filtering may be the problem.Anonymous
March 08, 2011
You know why IE 9 will fail? It's not because we all hate IE 6, but because users rely on plugins. The browser it's not just a client rendering engine, if that was the case we could ship just webkit. The web is all about PLUGINS/ADDONS. There are tons of addons for the other browser, such as Mozilla Firefox and Chrom(e/ium). Developers are very motivated to create plugin for OPEN browsers or browsers that RESPECT standards (Opera). Now IE don't respect standars nor is open. So, in conclusion, IE is a fail.Anonymous
March 08, 2011
Marcos: Uh, Opera isn't exactly a success story, nor do they have a successful plugin model. Chrome and Firefox both have plugin models that aren't based on open standards, and they break many plugins with every release of their browser. Of all the browsers, only IE has managed to keep most of their browser plugins working from one release to the next. So, in conclusion, your comment is a fail.Anonymous
March 08, 2011
Title:DEP/ASLR Implementation Progress in Popular Third-party Windows . Ref:secunia.com/.../DEP_ASLR_2010_paper.pdf
- Google Chrome While DEP has been enabled on both Windows 7 (Vista) and Windows XP from the first 1.x stable releases (late 2008), the icudt42.dll library is loaded at fixed address 0x4AD00000 in version 4.1.249.1064. Other icudt*.dll versions are loaded at fixed addresses in previous versions. The first stable version to enable dynamic allocation of the library was 5.0.375.55, released May 2010
Anonymous
March 09, 2011
Hi, When you say "eliminate predictable memory mappings" it is unclear to me; do you mean to say you've eliminated some of the DLLs that were not randomized? Or did you address issues with deterministic TEBs, not-nearly random enough thread stack layouts that lead to lols for stack addresses? Is the system call interface page now randomized? et ceteraAnonymous
March 10, 2011
The comment has been removedAnonymous
March 10, 2011
What a bunch of useless comments here. I'd like to thank ieblog, Eric and Microsoft for the great job they did on Windows 7 and IE 9. Rock on.