Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) have proven themselves to be important and effective countermeasures against the types of exploits that we see in the wild today. Of course, any useful mitigation technology will attract scrutiny, and over the past year there has been an increasing amount of research and discussion on the subject of bypassing DEP and ASLR [1,2]. In this blog post we wanted to spend some time discussing the effectiveness of these mitigations by providing some context for the bypass techniques that have been outlined in attack research. The key points that should be taken away from this blog post are:
In a previous blog post series we went into detail on what DEP is and how it works[part 1, part 2]. In summary, the purpose of DEP is to prevent attackers from being able to execute data as if it were code. This stops an attacker from being able to directly execute code from the stack, heap, and other non-code memory regions. As such, exploitation techniques like heap spraying (of shellcode) or returning into the stack are not immediately possible.
The effectiveness of DEP hinges on the attacker not being able to 1) leverage code that is already executable or 2) make the attacker's data become executable (and thus appear to be code). On platforms without ASLR (that is, versions of Windows prior to Windows Vista), it is often straightforward for an attacker to find and leverage code that exists in modules (DLLs and EXEs) that have been loaded at predictable locations in the address space of a process. Return-oriented programming (ROP) is perhaps the most extensive example of how an attacker can use code from loaded modules in place of (or as a stepping stone to) their shellcode [3,1]. In addition to loaded modules, certain facilities (such as Just-In-Time compilers) can allow an attacker to generate executable code with partially controlled content which enables them to embed shellcode in otherwise legitimate instruction streams ("JIT spraying").
The fact that modules load at predictable addresses without ASLR also makes it possible to turn the attacker's data into executable code. There are a variety of ways in which this can be accomplished, but the basic approach is to use code from loaded modules to invoke system functions like VirtualAlloc or VirtualProtect which can be used to make the attacker's data become executable.
Summary: DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not robust enough to prevent arbitrary code execution in most cases.
Attackers often make assumptions about the address space layout of a process when developing an exploit. For example, attackers will generally assume that a module will be loaded at a predictable address or that readable/writable memory will exist at a specific address on all PCs. ASLR is designed to break these assumptions by making the address space layout of a process unknown to an attacker who does not have local access to the machine. This prevents an attacker from being able to directly and reliably leverage code in loaded modules.
The effectiveness of ASLR hinges on the entirety of the address space layout remaining unknown to the attacker. In some cases memory may be mapped at predictable addresses across PCs despite ASLR. This can happen when DLLs or EXEs load at predictable addresses because they have not opted into ASLR via the /DYNAMICBASE linker flag. Prior to Internet Explorer 8.0 it was also possible for attackers to force certain types of .NET modules to load at a predictable address in the context of the browser. Attackers can also use various address space spraying techniques (such as heap spraying or JIT spraying) to place code or data at a predictable location in the address space.
In cases where the address space is initially unpredictable an attacker can attempt to discover the location of certain memory regions through the use of an address space information disclosure or through brute forcing. An address space information disclosure occurs when an attacker is able to coerce an application into leaking one or more address (such as the address of a function inside a DLL). For example, this can occur if an attacker is able to overwrite the NUL terminator of a string and then force the application to read from the string and provide the output back to the attacker . The act of reading from the string will result in adjacent memory being returned up until a NUL terminator is encountered. This is just one example; there are many other forms that address space information disclosures can take.
Brute forcing, on the other hand, can allow an attacker to try their exploit multiple times against all of the possible addresses where useful code or data may exist until they succeed. Brute forcing attacks, while possible in some cases, are traditionally not practical when attacking applications on Windows because an incorrect guess will cause the application to terminate. Applications that may be subjected to brute force attacks (such as Windows services and Internet Explorer) generally employ a restart policy that is designed to prevent the process from automatically restarting after a certain number of crashes have occurred. It is however important to note that there are some circumstances where brute force attacks can be carried out on Windows, such as when targeting an application where the vulnerable code path is contained within a catch-all exception block.
Certain types of vulnerabilities can also make it possible to bypass ASLR using what is referred to as a partial overwrite. This technique relies on an attacker being able to overwrite the low order bits of an address (which are not subject to randomization by ASLR) without perturbing the higher order bits (which are randomized by ASLR).
Summary: ASLR breaks an attacker's assumptions about where code and data are located in the address space of a process. ASLR can be bypassed if the attacker can predict, discover, or control the location of certain memory regions (particularly DLL mappings). The absence of DEP can allow an attacker to use heap spraying to place code at a predictable location in the address space.
In the previous sections we described the effectiveness of DEP and ASLR in isolation from one another. In reality, DEP and ASLR are designed to be used in combination on Windows Vista and beyond. Both of these mitigations are enabled in the context of important applications like Internet Explorer 8, Microsoft Office 2010, and in-box services and applications that ship with the OS. This means that attackers looking to exploit vulnerabilities in these environments will need to overcome both obstacles (in addition to numerous other mitigations).
The DEP+ASLR bypass techniques that are currently being explored in attack research have primarily focused on identifying and refining methods of bypassing ASLR. Once ASLR has been bypassed it is typically straightforward to bypass DEP using established techniques such as return-oriented programming. At this point in time there have been multiple exploits which have demonstrated that it is possible in practice to bypass the combination of DEP+ASLR in the context of certain application domains (such as browsers and third party applications). These exploits have bypassed ASLR through the use of predictable DLL mappings, address space information disclosures, or JIT spraying and have bypassed DEP through the use of return-oriented programming (or some simpler variant thereof) or JIT spraying. In many cases these exploits have relied on predictable mappings caused by DLLs that ship with third party components or by JIT compilation capabilities included in non-default browser plugins. This means that these exploits will fail if the required components are not installed.
Although exploits have been written which are capable of bypassing the combination of DEP+ASLR, the vast majority of exploits that have been written to date do not have such capabilities and instead strictly target applications and platforms that do not enable these mitigations. This affirms our position that DEP+ASLR are strong countermeasures for the types of attacks that we see in the wild today despite weaknesses in their current implementations.
Summary: DEP+ASLR are most effective when used in combination; however, their combined effectiveness is heavily dominated by the effectiveness of ASLR. Exploits have been developed that are able to bypass DEP+ASLR in the context of browsers and third-party applications. Nevertheless, the vast majority of exploits written to date do not attempt to bypass the combination of DEP+ASLR.
As we look toward the future it is clear that attackers will continue to become increasingly incentivized to attempt to develop exploits which are capable of bypassing the combination of DEP+ASLR. Our understanding of the ways that DEP and ASLR can be bypassed directly informs the future work we are doing to improve the robustness and resiliency of our mitigation technologies. Although this work is ongoing there are two noteworthy improvements that we would like to highlight.
These two improvements help to further illustrate our belief that DEP, ASLR, and exploit mitigations in general are extremely important due to the impact they have on the cost of developing reliable exploits and due to the knowledge demands they place on attackers. Mitigations such as these enable us to be proactive about providing additional protection to customers who may be running software with an unknown or unpatched vulnerability. Ultimately our goal with exploit mitigations is to reach a point where vulnerabilities become too expensive to reliably exploit - and this is a goal we are actively working toward.
We recommend that enterprises and users enable DEP for all critical applications and run a version of Windows that supports ASLR (such as Windows 7). The Enhanced Mitigation Experience Toolkit (EMET) can be used to easily enable DEP and other mitigations for a process. You can read more about EMET here:
The effectiveness of mitigations like DEP and ASLR across the Windows ecosystem is heavily contingent on ISV adoption. ISVs that are interested in more details on how to enable DEP, ASLR, and other mitigations in their products are encouraged to refer to the guidance below:
Matt Miller, MSEC Security Science
 Dino Dai Zovi. Practical Return-Oriented Programming. April, 2010.
 Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. February, 2010.
 Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. August, 2008.
 Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. March, 2010.
 Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004.
 Alexander Sotirov and Mark Dowd. Bypassing Browser Memory Protections. August, 2008.
*Posting is provided "AS IS" with no warranties, and confers no rights.*
Today we released Security Advisory 2488013 to notify customers of a new publicly-disclosed vulnerability in Internet Explorer (IE). This vulnerability affects all versions of IE. Exploiting this vulnerability could lead to unauthorized remote code execution inside the iexplore.exe process.
Proof-of-concept exploit bypasses ASLR and DEP
The Metasploit project recently published an exploit for this vulnerability using a known technique to evade ASLR (Address Space Layout Randomization) and bypass DEP (Data Execution Prevention).
In a few words, Internet Explorer loads mscorie.dll, a library that was not compiled with /DYNAMICBASE (thus not supporting ASLR and being located always at the same base) when processing some html tags. Attackers use these predictable mappings to evade ASLR and bypass DEP by using ROP (return oriented programming) gadgets from these DLLs in order to allocate executable memory, copying their shellcode and jumping into it. Note that without that predictable mapping, the only public ways to evade ASLR and DEP is through:
We have recently blogged on the effectiveness of ASLR and DEP here.
Recommendation: Use Enhanced Mitigation Experience Toolkit (EMET) to dynamically rebase all loaded DLLs
In order to minimize the risk of exploitation, users could install EMET and proceed to protect the iexplore.exe process as shown in the BlueHat video.
Exploits that attempt to bypass ASLR and DEP would use several ROP gadgets for several purposes. To understand why EMET is an effective workaround for these exploits, let’s focus on the stack pivot gadgets which set the stack pointer to the attacker controlled data (heap spray in our case):
0:000> u 63f0575b L4
63f0575b 94 xchg eax,esp
63f0575c 8b00 mov eax,dword ptr [eax]
63f0575e 890424 mov dword ptr [esp],eax
63f05761 c3 ret
When EMET is in place, this type of exploit will most likely fail. This is because of at least three mitigations:
Although the later two mitigations in the list above are not bullet proof and can be evaded, Mandatory ASLR is a solid one for closing the mscorie.dll exploitation vector. When the exploit attempts to jump into the ROP gadget that it believes to be at a predictable memory address, it will hit an access violation and crash the process:
0:000> u 63f0575b L4
63f0575b ?? ???
^ Memory access error in 'u 63f0575b l4'
And the exploit will fail.
Thanks to Richard van Eeden, Bruce Dang, and Jonathan Ness from the MSRC Engineering team for the help investigating this issue.
Fermin J. Serna, Security Software Engineer
There has been some discussion around a publicly posted PoC code that exploits a vulnerability in IIS FTP 7.5, which ships with Windows 7 and Windows Server 2008 R2. Our engineering team is looking into the situation and has made a few preliminary observations that might clear up some confusion. We’ve observed three notable characteristics.
First, this is a Denial of Service vulnerability and remote code execution is unlikely. The vulnerability occurs when the FTP server attempts to encode Telnet IAC (Interpret As Command) character in the FTP response. The IAC character, which is represented as decimal 255 (Hex FF) in the response, needs to be encoded by the addition of another decimal 255 character in the FTP response where we find the presence of the IAC character. Due to an error in this processing, it is possible to get into a state where an attacker could overwrite a portion of the response with a string of 0xFFs even past the end of the heap buffer, resulting in a heap buffer overrun.
In that situation, the only data that a malicious client controls in this overrun is the number of bytes by which the buffer is overrun. It cannot control the data that is overwritten -- the data will always be the IAC character 0xFF. Also, the malicious client does not control the addresses where data is overridden, and the data is always overridden in a sequential manner. The FTP service 7.5 is also protected by Data Execution Prevention (DEP). The combination of these characteristics makes it difficult to successfully execute a heap spray or partial function pointer override attack. Because of the nature of the overrun, the probable result will only be a denial of service and not code execution.
Our second discovery is that this vulnerability only affects IIS FTP Service and leaves the IIS Web Services completely unaffected. Hence a Denial of Service on the FTP service will not affect any of the web services hosted by IIS but only the FTP service.
Third and finally, the IIS FTP Service is not installed by default, and even after installation, it is not enabled by default. A user can determine the status of the IIS FTP service by querying it through the command prompt (running as administrator):
· Press the “Windows”+“R” key
· Type “cmd.exe” (no quotes)
· In the command prompt type “sc query ftpsvc” (no quotes)
· If the service is not installed then the following will be displayed:
> sc query ftpsvc
[SC] EnumQueryServicesStatus:OpenService FAILED 1060:
The specified service does not exist as an installed service.
· If the service is installed and running then the following will be displayed:
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
We’ll continue to investigate this issue and, if necessary, we‘ll take appropriate action to help protect customers. This may include providing a security update through the monthly release process or additional guidance to help customers protect themselves.
Thanks the MSRC Engineering for the help in looking into this issue.
Nazim Lala, IIS Security Program Manager
Today we released MS10-104 to address vulnerability CVE-2010-3964 in SharePoint 2007 server with an important severity rating. In this blog, we would like to cover some additional details of this vulnerability.
Is my SharePoint server affected by this vulnerability?
There are two types of installations for a SharePoint server: standalone and farm. A standalone installation is used for test/evaluation purposes and cannot be used when creating a SharePoint farm. With a farm installation there are two sub-types: complete and web front end. Servers of both types can be used to form a SharePoint farm. This is how SharePoint server is intended to be used for production deployment.
The following screen capture shows the server types you can select during SharePoint installation
By default, the vulnerable service, "Office Document Conversions Launcher Service", is disabled in SharePoint farm installations. It is, however, enabled for SharePoint standalone installations. Most likely a SharePoint server in production will be deployed in the farm mode, and thus not vulnerable by default.
You can check whether the "Office Document Conversions Launcher Service" is running on your SharePoint server with the command “sc query dclauncher”. If the service is running, then the SharePoint server is vulnerable.
What is the restricted guest account mitigation?
While the "Office Document Conversions Launcher Service" runs under the localsystem account, the actual document conversion process is launched under a special HYU_<ServerName> account. This is a guest account created by SharePoint server and is used only for document conversion. Thus, even if the attacker manages to get the malicious code runs, the code will run under this guest account.
Would disabling the “Office Document Conversions Load Balancer Service” or blocking TCP port 8093 be good workarounds?
In the bulletin, we list workarounds that involve disabling the "Office Document Conversions Launcher Service" or blocking TCP port 8082. In normal scenarios, the user needs to first retrieve a launcherUri through a different service called the “Office Document Conversions Load Balancer Service” before connecting to the “Office Document Conversions Launcher Service”. On first look it apears that disabling or blocking access to the load balancer service would also be an effective workaround. However, you should note the launcherUri has a predictable format and could be guessed by an attacker. They could simply connect to the “Office Document Conversions Launcher Service” directly and reach the vulnerability. Therefore, just disabling “Office Document Conversions Load Balancer Service” or blocking the TCP port 8093, which it runs on, would not stop the vulnerability from being triggered.
How can I know if my server was attacked?
The SharePoint ULS (Unified Logging Service) logs are saved under \Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. You can review all entries with “Microsoft.Office.Server.Convers (0x12CC) 0x1750 Document Conversions Launcher Service” to check for abnormal document conversion requests.
Thanks to Robert Orleth on the SharePoint team and Mark Debenham for their work on this case.
-Chengyun Chu, MSRC Engineering
-Chengyun Chu, MSRC Engineering
This month we shipped a security update and bulletin (ms10-105) to address vulnerabilities in the .cgm, .tif, .fpx, and .pct image filters. These filters are shipped with Microsoft Office to extend image rendering for applications. Neither Office 2010 nor Office 2007 use filters to perform rendering by default. Both use GDI+ instead. Historically, if an image filter was incapable of rendering an image and GDI+ supported the image format, GDI+ would be asked to render the image. GDI+ worked as a backup renderer. The newer versions of Office have switched to using GDI+ as the default render and have also deprecated the use of some filters.
What the update does
The update will include an updated version of .pct filter to address a vulnerability found in that filter. In addition to that the update makes GDI+ the default renderer on versions of Office prior to 2007 (as opposed to using the filters that ship with Office). Beyond this, a filter allow-list was backported from Office 2010 and Office 2007 to downlevel versions of Office. The allow-list enables commonly used filters and disables other legacy filters. However, if needed administrators can re-enable the legacy filters through a registry key.
Registry Location: HKLM\software\microsoft\office\common\security\allowlists\graphicsfilterimportName: AllowListEnabledType: DWORDDescription: This registry key controls whether an allow-listshould be used for image filters. If this registry key is set to 1, Office will look at other keys in the same registry location for filters to enable. The filters to enable are specified by creating a new string value for each filter with a name of FILTER.FLT (where FILTER.FLT is the name of a real filter) and a value of the format XX.YY.ZZ.WW (where XX, YY, ZZ and WW specify the version of the filter).Values:
For more details on the allow-list and some examples of how to use it, please refer to the KB article at http://support.microsoft.com/kb/2479871.
Thanks to Modesto Estrada, the Office team, Brian Cavenah, and Andrew Roths for their efforts shipping this update.
Today we released seventeen security bulletins. Two have a maximum severity rating of Critical, fourteen have a maximum severity rating of Important, and one has a maximum severity rating of Moderate. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
Most likely attack vector
Max Bulletin Severity
Likely first 30 days impact
Platform mitigations and key notes
Victim browses to a malicious webpage.
Public exploit exists for CVE-2010-3962. Exploits works on IE6 and IE7 on Windows XP.
We have not seen CVE-2010-3962 exploits that have successfully bypassed DEP. Therefore, IE8 users are at reduced risk.
(Opentype Font driver)
Victim using explorer.exe browses to a folder containing a malicious OTF file.
Likely to see an exploit released granting a local attacker SYSTEM level access.
Windows XP and Windows Server 2003 not vulnerable to the shell preview attack vector.
Attacker running code on a machine already elevates from low-privileged account to SYSTEM.
This vulnerability being exploited by Stuxnet malware.
Victim opens a malicious Office document
Likely to see an exploit released for one or more of the CVE’s addressed by this bulletin.
Later versions of Microsoft Office have disabled support for several of these graphics filters. Please see SRD blog post here for more detail.
Victim opens a malicious .PUB file
Likely to see an exploit released.
Systems that have not configured a VPN or RAS connection are not vulnerable by default.
DLL Preloading Issues
(MS10-093, MS10-094, MS10-095, MS10-096, MS10-097)
Victim browses to a malicious WebDAV share and launches an application by double-clicking a content file hosted on the attacker-controlled WebDAV share.
Public proof-of-concept code already exists for several of these vulnerabilities.
Attacker sends malicious RPC network request to Windows Server acting as a domain controller. Request must be sent from a domain-joined workstation on which the attacker has administrative privileges. The request could bugcheck the Windows server.
Due to the mitigating factors, unlikely to see wide-spread exploitation for denial of service.
Attacker must have administrative rights on a domain-joined machine to launch this attack.
Attacker with administrative control of a guest OS can bugcheck (reboot) the host OS.
Unlikely to see wide-spread exploitation of this denial-of-service issue.
Attacker running code on a machine already elevates from low-privileged account to the workstation account (Machine$).
While an exploit could be developed for this issue, the severity of the elevation is limited. This is not a typical elevation of privilege vulnerability which would result in administrative control of the system.
If an off-by-default service is enabled, an attacker can upload a malicious executable and potentially cause it to be run with Guest privileges on Sharepoint Server.
Unlikely to see wide-spread exploitation as the service is not enabled by default.
Sharepoint servers in production unlikely to be vulnerable by default. See this SRD blog post for more information.
Attacker sends malicious RPC network request to an Exchange Server causing it to enter an infinite loop denial-of-service condition. The specific RPC function requires the attacker to be authenticated.
Thanks to the whole MSRC Engineering for their work on this month’s cases.
- Jonathan Ness, MSRC Engineering