Enhanced Memory Protections in IE10

Internet Explorer 10 introduces significant improvements in memory protections to help make vulnerabilities harder to exploit, helping to keep users safe on the sometimes-hostile Web. These improvements will increase the difficulty and development cost of exploits, making life harder for the bad guys.

While socially-engineered malware is the primary way that bad guys get their code onto victims’ computers, that is largely because browser vulnerabilities have become less common and harder to exploit over the last few years. However, as more and more users upgrade to IE9 and benefit from the protection provided by SmartScreen Filter, bad guys have a renewed interest in attacking the browser and its add-ons directly.

In today’s post, I explain the threat environment, survey the existing protections available in IE9, and explain how IE10’s new memory protections provide even more security.

Attacking Web Browsers

The goal of an attacker exploiting a memory-related vulnerability is to cause the browser’s path of code execution to deviate into code of the bad guy’s choosing. To achieve this, the attacker needs two things to be successful. They need to have code available on the victims’ machine that they wish to run. The techniques used to obtain such code can be grouped into two classes. An attacker can place their own malicious code into memory using techniques like heap spraying. Or an attacker can select code to execute that is already present in memory using a technique called Return Oriented Programming.

The attacker also needs to be able to exploit a vulnerability that allows the flow of code execution to be altered from design, such as a buffer overflow vulnerability. Then they can change the code path to “jump to” the address of the code they want executed.

In a typical buffer overflow attack, a carefully crafted data set is placed on the thread’s stack, overflowing its assigned buffer and overwriting other data structures. Attackers attempt to overwrite structures like exception handler records, or the return address of the function, which would allow them to change the flow of code to a location in memory of their choosing.

Diagram illustrating that when the amount of data written to a local buffer exceeds its allocation, critical portions of the stack can be overwritten and could cause a crash. By submitting carefully crafted data, an attacker can overwrite the return address, changing the flow of code execution to an arbitrary memory location.

Other types of attacks include use-after-free vulnerabilities, in which the application is tricked into accessing a released object whose memory has been reused for some other purpose.

Defending the Browser

Memory protection technologies provide a front line of defense to block attackers from achieving their goals. These technologies exist to make exploiting vulnerabilities more difficult, less reliable, and in some cases impossible. Memory protections aim to safely terminate a browser process under attack before a vulnerability can be successfully exploited to run the attacker’s code. In many cases, protections allow vendors time to produce and distribute a fix before a vulnerability can be exploited to cause damage.

The Memory Mitigation Technologies employed by Internet Explorer have evolved over time to help defend against new attack techniques as they are developed and popularized. Many defenses, like the /GS compiler flag, have been used by previous versions of Internet Explorer but are updated and enhanced over time. Some defenses, like ForceASLR (described shortly) are new to IE10 and rely on new operating system features.

Compile time mitigations

Compiler mitigations are available to software developers and should be applied as part of a development best practice. The Internet Explorer team includes these mitigations during the development Internet Explorer as a requirement of our Security Development Lifecycle. We encourage software developers to adopt their own SDL process that include implementation of these compile time mitigations.

The /GS flag was first introduced in Visual Studio .NET 2002 and has been used by all supported IE versions. It is a compiler technology which adds a Buffer Overrun Detection capability to an application’s stack. Security secrets known as “canaries” are added to application’s stack boundaries at runtime. For example, a canary placed between a stack buffer and a return address, will be overwritten by a buffer overflow attack targeting the return address. This provides a means for the process to detect that an overflow has occurred. An exception will be raised and the process can be safely terminated before the attacker’s code is run.

Diagram showing how a security secret is placed between local variables and the return address. Before the function returns, teh value of the secret is compared with the original. If the comparison fails, an exception is raised and the process can be safely terminated.

This basic protection concept has been improved in each new version of Visual Studio. The latest version of Enhanced /GS, used by Internet Explorer 9+, includes greatly improved heuristics to protect more functions, including Non-Pointer arrays and pure data structures. In addition, improved optimization has eliminated unnecessary checks, decreasing the performance cost of the defense.

The /SAFESEH flag is a linker option that provides a mechanism for an application’s registered exception handlers to be stored in a lookup table in a secure memory location. In the event of an exception, the exception handler addresses on the application’s stack are validated against the lookup table. If the values do not match, the process will be terminated.

Diagram showing that exception registration addresses are compared with the values stored in lookup. If the values don't match, an exception is raised and the process is terminated.

One problem with the /SAFESEH flag is that it requires all DLL modules to opt-in to the protection to reliably protect the process. If any module does not opt-in, protection is less effective. While the SDL requires that all of Microsoft’s code be compiled with SAFESEH, third-party add-ons might not be compiled with the flag.

The /DYNAMICBASE flag is a linker option that opts an application into an operating system mitigation known as Address Space Layout Randomization (ASLR), discussed in more detail later in this post.

Similarly to the /SAFESEH limitation, a problem with the /DYNAMICBASE flag is that any DLL module that doesn’t opt-in to this protection reduces the value of ASLR as an exploit mitigation. Any module at a predictable location can be targeted by an attacker, and an exploit may only require one such predictable target. Many recent exploits target browser add-ons that don’t opt-in to the protection of ASLR. For instance, an Adobe Reader and Acrobat 0-day exploit in 2010 relied on the predictable location of functions within a module named icucnv36.dll that failed to opt-in to ASLR.

Run time mitigations

Runtime mitigations allow the operating system to help participate in keeping the process secure.

DEP/NX is an operating system mitigation that relies upon key security features (Data Execution Prevention or No eXecute) of modern CPUs. This mitigation enables memory pages to be marked as non-executable (Data); the processor will refuse to run code on a memory page so marked.

In the second stage of a memory exploit, an attacker may try to execute their own code which they have added to a data page in memory. In scenarios where the data page has been marked as non-executable, the attacker’s code will fail to run and the process will be safely terminated.

DEP/NX support was first enabled by default in IE8, and remains enabled in IE10.

SEHOP is a runtime mitigation that provides an exception-handler tamper-protection mechanism much like the /SAFESEH compiler flag. This protection works by inserting a symbolic exception record as the tail record in the thread’s exception handler list. In the event of an exception, the exception handler list is walked to ensure that the symbolic record can be reached. If it cannot be reached, this indicates that the exception handler chain is corrupted and the process will be safely terminated. Unlike SafeSEH, SEHOP does not require each individual module to opt-in, and thus it provides protection even if add-ons were not compiled with the most secure flags.

SEHOP was first enabled in IE9 and remains enabled in IE10.

Address Space Layout Randomization was first introduced in Windows Vista and has been greatly improved in Windows 8. ASLR assigns applications a random base memory address when they are initially loaded into memory. In addition, other memory structures such as the Process Environment Blocks (PEB), Thread Environment Blocks (TEB), Stacks and Heaps are also assigned to random locations in memory.

Randomizing the location of objects and functions in memory helps prevent an attacker from discovering where they are, which helps prevent a technique called Return Oriented Programming. This randomization can be thought of as securing the attacker’s payload with a combination lock. If an attacker doesn’t have the combination, they only get one guess. Guessing wrong means the attack will fail and the process will safely be terminated.

The following illustration depicts how core system components are loaded in random memory addresses on system startup.

Diagram showing how the physical memory location of various system DLLs changes between a first and second boot.

ASLR in Windows 8 has seen a number of improvements, all of which are utilized by Internet Explorer 10.

All Bottom-Up and Top-Down allocations are now randomized using 8 bits of entropy. This improvement significantly reduces predictable memory regions including VirtualAlloc and MapViewOfFile.

High Entropy Address Space Layout Randomization (HEASLR) takes advantage of the increase in 64bit address space and assigns more bits to entropy. This has the effect of drastically increasing the number of potential addresses that may be assigned to a 64bit process. All 64bit processes can opt-in to the increased entropy made available by HEASLR. Processes can opt-in either at link time (/HIGHENTROPYVA) or at load time via a new Image File Execution Option.

By default, the Metro style browser runs in 64bit mode on 64bit computers, providing a much larger address space and thus more random memory layout.

ForceASLR is arguably the most important change to ASLR in Windows 8. ForceASLR is a new loader option used by Internet Explorer 10 to instruct the operating system to randomize the location of all modules loaded by the browser, even if a given module was not compiled with the /DYNAMICBASE flag. The ForceASLR protection was added to the Windows 8 kernel, and the feature is now available as an update to Windows 7 that will be installed when Internet Explorer 10 is installed on that platform.

To help ensure compatibility with this feature, and to provide memory-randomization protection to older Internet Explorer versions that don’t support ForceASLR, we continue to recommend that add-on developers make use of the /DYNAMICBASE flag.


I hope this brief overview of the memory protections present in Windows 8 and Internet Explorer 10 has proven valuable. Under the covers, we’ve made many other tweaks for enhanced security, but many of them are so esoteric that we don’t even have names for them. We do have a few more security-related announcements coming, so stay tuned for updates as we continue our mission to deliver a secure Web browsing platform.

—Forbes Higman, Security Program Manager, Internet Explorer

Comments (19)

  1. Arieta says:

    How much of these will be present in IE10 for Windows 7?

  2. EricLaw [MSFT] says:

    IE10 on Windows 7 will opt-in to ForceASLR on Windows 7. HEASLR and other ASLR improvements are new to Win8 and only available on that platform. IE10 on Win7 also benefits from the compile-time mitigations mentioned here, and may be configured to run in 64bit mode for enhanced security.

  3. Simon says:

    Sorry for this long post! I work in tech support for non-tech computer owners.)

    (Also sorry if this turns into a doublepost – not seen any sign of it going through yet.)

    The latest hacking contests manage to break both MSIE & Chrome, but the VUPEN(?) team described MSIE as having lots of memory corruptions, which didn't sound too good.

    (arstechnica.com/…/ie-9-on-latest-windows-gets-stomped-at-hacker-contest.ars -> @The IE sandbox is less restrictive ___and has many memory corruptions___, which is not the case with the Google chrome sandbox.@)

    I know that Win8 MSIE10 has the option for a more restrictive sandbox (even for the desktop) but I don't know what memory corruptions are (in a hacking sense). Is there any comment on this for a layman such as myself – or how to reduce the risk?

    If not, then on my own machine I :

    1) Set all bar untrusted sites to @High@ security, but re-enabled file download and active scripting;

    2) Run with no plugins (bar silverlight);

    3) Enable activex filtering.

    I can't set all of these restrictions on my customers' pcs, but I explain about activex filtering, mixed-security prompts and plugins; and I disable @Launching programs and files in an iframe@. All of these changes, though, still leave me open to having to explain myself again if those settings cause a problem. Are there any obvious settings that I've overlooked which someone would suggest disabling? Will MS look at disabling more options (at least in the metro browser) by default? (I definitely applaud the no-plugins feature.) :) m(_ _)m

  4. EricLaw [MSFT] says:

    @Simon: As mentioned in this post, data shows that the vast majority of compromises are related to socially-engineered malware, so the single best thing you can do for security is run IE9 or later with SmartScreen enabled.

    The most important setting in the High template is "Active Scripting", although it's true that you pick up some defense-in-depth from restricting other settings. In particular, running with ActiveX Filtering is a great reduction in attack surface, helping to shield plugins from vulnerabilities. The ForceASLR feature described here helps as well.

  5. Managed code browser says:

    Why mess around with native code with this type of memory manipulation power? If we're going plug-in free, write the browser in .NET 4.5 already…

  6. Steve Hayter says:

    @Managed code browser – no doubt because it would be dog slow. I love managed code, but with the amount of work a web browser does, I doubt it would perform very well.

  7. Simon says:

    @EricLaw: Thanks for the reply! m(_ _)m

    REF: active filtering; I guess sod's law says that the one featuere so many websites don't work without is also the one that is the most dangerous. :|

    For general computer users, smartscreen and general compatibility with current websites are probably the two biggest reasons that make me recommend msie over chrome. (In contrast activex filtering is more of a reason not to recommend against msie – as well as the useful activex theres lots of dangerous or badly written activex out there (flash et al), but at least it can be switched off by default.) I believe that chrome has recently added something similar to smartscreen, but I've seen no word on how effective it is yet… Hopefully msie can add even more security features in the future.

  8. Bob says:

    Can you guys add native sandboxing to windows (something similar to what the SandboxIE program does). Basically, you can create an arbitrary number of sandboxes:

    1. the windows APIs are wrapped so that programs running outside a sandbox can't see programs running inside one (and vice versa). i.e. programs in a sandbox think they're the only ones running on a system.

    2. all writes (and optionally reads) to the registry and filesystem in a sandbox are tunneled to a different location (and also a diff tool should be included so you can examine what changed).

    3. include the option to run programs in a fresh temporary sandbox (i.e. the sandbox is deleted when all programs running inside it exit) each time.

    This way if a sandboxed IE gets exploited, only the phony windows environment the sandboxed IE was running in will be tampered with.

  9. Brenno says:

    Is /ForceASLR a PE flag (speak something for the PE loader to detect and nothing the applications needs to be compiled for) or a an API call done by the application? Will it be available to other applications? Will the update that adds ForceASLR support to the Win7 kernel be only available in conjunction with IE10?

  10. I Can Haz Proper English says:

    I think you want: "Enhanced Memory Protection" (no "s"). The plural of protection is protection.

    Otherwise it sounds like your are only try to spread informations around the interwebz (sic, sic, sic, sic)

  11. just 2 days back i was browsing a web site (news web site – x17online.com) in IE and my computer got affected by Alureon.A trojan. my pc was fully patched. even though it got affected. removal process of that trojan is a hell even though i am a tech guy, than just imagin what would happen to non tech user. i dont know some how its very easy to get  virus from IE.

  12. bricky149 says:

    I think memory protections like this are ingenious, but something tells me you're sharing this now to revalidate the point that Chrome got hacked 3 times altogether at both Pwnium and Pwn2Own through Chrome's coding. These protections will prevent that, right?

  13. Viktor Krammer [Quero] says:

    Why is there no option to swtich tabs to 64-bit in Desktop IE10 on the Windows 8 Consumer Preview? Only way I found is to enable Enhanced Protected Mode, but EPM runs plug-ins free. I think there should be a 64-bit mode, which also allows 64-bit add-ons and plug-ins like the IE9 64-bit edition does.

  14. Harold says:

    Ok, this is extremely off topic but I haven't found a definitive source from Microsoft that answers the following question (unfortunately needed due to IE9 incompatibilities still under investigation) and this is the best place on the Internet to get any response/attention from Microsoft.

    We have clients that are buying Windows 7 laptops/desktops that come pre-installed with IE9. (e.g. They never had IE8 installed)

    The question is, can IE9 be downgraded to IE8 on these machines?  The documentation here suggests it can be done, but I need confirmation before telling my client that it is possible based on hearsay.

    **Yes I'm totally aware that downgrading is not the best option, fixing the app that doesn't work on IE9 is the priority… however in the mean time I need a solution to ensure clients can use the app**

    Please note… if you want to reply with what you "think" is the answer… DON'T… I'm looking for cold hard facts… from a reliable source…


  15. Stifu says:

    @Harold: just in case, did you try adding a X-UA-Compatible meta to your site, to force IE8 rendering even when using IE9?

  16. SanC says:

    @7tester : I'm guessing you didn't agree to run or launch any files, so perhaps you had something like java or flash installed and enabled? Even without plugins there's no major browser that is 100% resistant to hacking, but with plugins it's a lot easier. If you have flash/java or other activex controls enabled, (but especially those two) then you're at much greater risk than in default configuration, unless you enable activex filtering to block those things.

    After that, running MSIE 64bit instead of 32bit (if possible) gives you some more security, though it might be slower in some areas. (Personally I take the speed hit just in case.)

    I also disable "Launch programs and files in an iframe". (This is a recommendation from msmvps.com/…/default.aspx – the reason given is that the bad guys/gals use it a lot more than the good ones. Probably thru adverts?)

  17. EricLaw says:

    @Brenno: On Win7, the only way to opt-in to ForceASLR is via an Image File Execution Options registry flag. The kernel update KB was pushed via WU yesterday. See support.microsoft.com/…/2639308

    @Harold: Yes, uninstalling IE9 will revert to the IE8 that shipped with Win7.

    @bricky149: As described in this post, memory protections make it harder to reliably exploit vulnerabilities to lead to code execution. However, they don't make exploitation "impossible" in general, although in some cases the protections cannot be circumvented. It depends on the nature of the vulnerability.

    @Viktor Krammer: Plugins may be designed to run in desktop IE in EPM. The user must have both 32bit and 64bit versions of the plugin installed, and the plugin must be listed within a particular COM Component Category to mark it as EPM compatible.

    @Bob: Sandboxing is, alas, far more complicated than most people think. Most "add-on" sandbox models are not actually secure because they're leaky; they're usually providing "security by obscurity" because so few people run them. In terms of supported, "native" sandboxes, you should read the 3/14/2012 post on Enhanced Protected Mode, which is based on the Win8 AppContainer sandbox.

  18. kudryavka says:

    Although written HEASLR can be setting also by IFEO, what is a setting name?

  19. kudryavka says:

    And, Is it inapplicable to all 64-bit process of whole system?