IE 10 ATTACKS -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.

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.

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.

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 last year 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.

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.

Summary

ITis easy ... I think ... !!!


Maquiavelo

FUENTE

Los mejores :-)
http://blogs.msdn.com/b/ie/archive/2012/03/12/