Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

August, 2009

  • MS09-039: More information about the WINS security bulletin

    This morning, we released security update MS09-039 addressing vulnerabilities in the Microsoft Windows Internet Name Service (WINS). In this blog post, we’d like to help you understand the following:

    • What is the risk of this vulnerability?
    • Why is it rated Critical?
    • What is Microsoft doing to prevent a “WINS worm?”
    • What you can do to protect your environment?

    What is the risk of this vulnerability?

    A remote, anonymous attacker could use CVE-2009-1923 (addressed by MS09-039) to force wins.exe to under-allocate a buffer and copy in attacker-controlled data. This could lead to heap corruption and potential code execution as SYSTEM. Therefore, it is important to apply this security update to affected servers.

    Why is it rated Critical?

    The last WINS security update addressing a remote code execution vulnerability was MS04-045, shipped in December 2004. MS04-045 addressed a remote code execution security vulnerability rated “Important.” The mitigating factor dropping the rating from the maximum “Critical” rating down to “Important” was the fact that WINS is not installed by default. MS09-039 has the same mitigating factor – WINS is still not installed by default. However, the most recent Security Development Lifecycle (SDL) bug bar has changed how we rate components necessary for critical infrastructure. Security bulletins affecting critical components on enterprise networks are no longer down-rated for being off by default. We know that enterprise networks will have WINS so while the mitigating factor applies, it does not change the bulletin severity.

    What is Microsoft doing to prevent a “WINS worm”?

    This vulnerability is fairly easily detectable on the wire. Microsoft has shared network detection guidance and sample vulnerability triggers with all our Microsoft Active Protections Program (MAPP) partners. They will be able to use this information to successfully build robust network signatures to detect and block attempts to exploit this vulnerability. If you cannot immediately apply the WINS security update to affected servers, we encourage you to roll out detection updates from your protection provider as they become available.

    What you can do to protect your environment?

    Any potential attacks against the vulnerabilities addressed by security update MS09-039 will arrive on TCP or UDP port 42. Block those ports at your perimeter firewall to prevent Internet-based attacks. Most enterprise networks require WINS internally so you’ll need to allow access from legitimate network workstations needing to resolve internal names.

    Hopefully this information helps you assess the risk of potential attacks against the vulnerabilities addressed by MS09-039.

    - Jonathan Ness, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MS09-037: Why we are using CVE's already used in MS09-035

    MS09-035 was released July 28 to address vulnerabilities in the Visual Studio Active Template Library (ATL). A related security update, MS09-034, included a defense-in-depth Internet Explorer mitigation to help protect against attacks in vulnerable components. This morning, we released security bulletin MS09-037 to addresses the ATL vulnerabilities in several Windows components.

    MS09-037 contains the following CVE’s:


    Two of these CVE’s, CVE-2009-2493 and CVE-2009-0901 were also listed in MS09-035. You might be wondering, shouldn’t they already be fixed by the previous security update? It’s a little bit tricky to understand so we’ve built a table that we hope will help.

      CVE-2009-2493 & CVE-2009-0901
    MS09-035 Addresses the vulnerability by releasing new ATL headers and libraries.
    MS09-037 Addresses the vulnerability by releasing updated versions of Windows controls affected by the vulnerability.

    So you can see that MS09-035 and MS09-037 both addressed different aspects of the same vulnerabilities.

    The three other CVE’s (CVE-2008-0015, CVE-2008-0020, CVE-2009-2494) describe vulnerabilities present in only Windows private branch of the ATL code. Because MS09-035 was an update for the public ATL headers and libraries released with Visual Studio, these CVE’s addressing vulnerabilities in the Windows private ATL code branch were not listed in bulletin MS09-035. There was no call- to- action related to these three new CVE’s for Visual Studio customers at the time of the MS09-035 security update.

    CVE-2008-0015 is a good example of our CVE usage. We used CVE-2008-0015 in MS09-032 to refer to the msvidctl.dll remote code execution vulnerability. When MS09-037 uses CVE-2008-0015 again, it is referencing the same vulnerability that was present in msvidctl.dll. For controls that have the exact same vulnerability and are being addressed by MS09-037, we use the same CVE again (CVE-2008-0015, in this case).

    We hope that helps you understand the ATL-related CVE’s.

    - Chengyun Chu, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • MS09-036: ASP.NET Denial-of-Service vulnerability

    We have released MS09-036 to address an anonymous denial of service (DoS) vulnerability in ASP.NET. We’d like to go into more detail in this blog to help you understand:

    • Which configurations are at risk?
    • What could happen if my configuration is impacted?
    • How can I protect myself?

    Which configurations are at risk?

    This vulnerability can only be triggered using ASP.NET on webservers running IIS 7 in integrated mode. So all the following configurations are not affected:

    • IIS6 server are safe;
    • IIS7 with application pools only in classic mode is safe;
    • IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 is safe.

    Windows 2000, Windows XP and Windows Server 2003 are not affected by this issue since IIS7 can only be installed in Windows Vista and Window Server 2008.

    Specifically, we would like to clarify the following questions:

    Question 1: Is the vulnerability in IIS7, or in

    This is an issue in, which is shipped as part of .NET Framework.

    Question 2: How could I know whether the version of .NET Framework installed in my Windows Vista/Windows 2008 machine contains vulnerable code or not?

    For Windows Vista, and Windows Server 2008, let’s take a look for the supported .NET Framework’s installation scenario. Also, note that Windows Server 2008 RTM shipped with Service Pack 1 of OS (see for more information)

      .NET Frameowrk 2.0/3.0 RTM .NET Framework 2.0/3.0 SP1 .NET Framework 2.0/3.0 SP2
    Windows Vista RTM Supported
    (in-box installation)
    Supported Supported
    Windows Vista SP1
    Windows Server 2008
    Not Supported Supported
    (in-box installation)
    Windows Vista SP2
    Windows Server 2008 SP2
    Not Supported Not Supported Supported
    (in-box installation

    For all the supported scenarios above, only .NET Framework 2.0/3.0 SP2 shipped with Windows Vista SP2/Windows Server 2008 SP2 are not affected. That’s why we said previously that IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 is safe.

    Question 3: I am confused. It is said that the vulnerability is in .NET Framework. How could the .NET Framework 2.0/3.0 SP2 on Windows Vista SP1 is affected while the .NET Framework 2.0/3.0 SP2 on Windows Vista SP2 is NOT affected?

    Due to the incremental build environment, the in-box .NET 2.0/3.0 SP2 version shipped with Windows Vista SP2 and Windows Server SP2 is not affected by this vulnerability. To clarify, even the version number (2.0/3.0 SP2) is kept the same, the in-box .NET 2.0/3.0 SP2 version shipped with Windows Vista SP2 and Windows Server SP2 has already included the fix of this vulnerability.

    Question 4: What about .NET Framework 3.5?

    .NET Framework 3.5 is built incrementally upon .NET Framework 2.0 and 3.0. In this context, .NET Framework 3.5 is equivalent to .NET Framework 2.0/3.0 SP1, and .NET Framework 3.5 SP1 is equivalent to.NET Framework 2.0/3.0 SP2. So if you have .NET Framework 3.5 SP1 installed on Vista RTM, SP1 or Windows Server 2008 RTM/SP1, you also have an affected version of .NET Framework 2.0 SP2 installed.

    What could happen if my configuration is impacted?

    The attack is a remote anonymous DoS attack to ASP.NET. In other words ASP.NET would stop processing requests. Therefore:

    • This is not a DoS against the underlying OS operating system (i.e. Windows).
    • This is not a DoS against IIS7. IIS7 is still running, which means if you have a webpage which does not require ASP.NET, the webpage would not be affected. Only web pages requiring ASP.NET functionality would be affected.

    How could I recover from the attack?

    Restarting IIS’s application pool will recover your application from the attack. You could do it via command-line utility iisreset.exe or IIS UI.

    UI: In the IIS Manager tool go to the “Application Pools” node. In the right-hand pane choose the application pool to recycle. Right click on the desired application pool and select “Recycle” from the pop-out menu. These steps are illustrated below.

    Mitigation and Workarounds?

    As indicated, IIS7 on Windows Vista SP2 or Windows Server 2008 SP2 are not affected. Therefore, you may consider upgrading your system to Windows Vista SP2 or Windows Server 2008 SP2. However there are potential compatibility issues developers should be aware of when upgrading ASP.NET applications to the version of the .NET Framework that is included in Windows Vista SP2 and Windows Server 2008 SP2. For a current list of known issues see

    Other options would be changing how IIS processes the requests for managed code. The workarounds listed in the security bulletin are examples of this approach.

    In IIS 7.0, application pools run in one of two modes: integrated mode and classic mode. The application pool mode affects how the Web server processes requests for managed code. If a managed application runs in an application pool with integrated mode, the Web server uses the integrated, request-processing pipelines of IIS and ASP.NET to process the request. However, if a managed application runs in an application pool with classic mode, the Web server continues to route requests for managed code through Aspnet_isapi.dll, processing requests the same as if you were running in IIS 6.0.

    For reference, here are a number of links that discuss ISAPI (i.e. classic mode) and integrated mode:

    As indicated in the bulletin, a viable workaround is to either configure the MaxConcurrentRequestsPerCPU registry key or maxConcurrentRequestsPerCPU attribute in the aspnet.config to shift request from the CLR threadpool (which is what ASP.NET is interacting with) to the IIS native threadpool.

    Update 8/17/2009: Bulletin number and hyperlink corrected.

    - Chengyun Chu, MSRC Engineering

    *Posting is provided "AS IS" with no warranties, and confers no rights.*

  • Preventing the exploitation of user mode heap corruption vulnerabilities

    Over the past few months we have discussed a few different defense in depth mitigations (like GS [pt 1, pt2], SEHOP, and DEP [pt 1, pt 2]) which are designed to make it harder for attackers to successfully exploit memory safety vulnerabilities in software. In addition to the mitigations that we’ve discussed so far, a significant amount of effort has gone into hardening the Windows heap manager in order to complicate the exploitation of heap-based memory corruption vulnerabilities. This hardening effort started with changes that were made in Windows XP SP2 and has continued on into Windows 7. In this blog post we will give a brief recap of the relevant changes that have been made to the Windows heap manager. We will also help shed some light on the state of the art in exploitation techniques for heap-based memory corruption vulnerabilities & what relevance those techniques have to Windows Vista, Windows Server 2008, and Windows 7.

    Heap mitigation techniques

    The hardening changes that have been made to the Windows heap manager generally fall into two categories: metadata protection and non-determinism. Metadata protection changes focus on protecting the integrity of various data structures that are used internally by the heap manager. These changes are useful because the majority of public exploitation techniques have traditionally relied on the corruption of one or more heap data structure. On the other hand, non-determinism changes focus on making the state of the heap unpredictable which has a direct impact on the probability that an exploit will succeed.

    Windows XP and Windows Server 2003

    The first set of heap hardening changes were released with Windows XP SP2 and Windows Server 2003 SP1. These changes included:

    • Safe unlinking: A verification check that occurs during free chunk unlinking which makes sure that the list entry stored in a free chunk is a valid doubly linked list entry (by checking E->F->B == E->B->F == E where E is the free chunk list entry). This prevents exploitation techniques that rely on using the unlink operation performed during the coalescing of free chunks to write an arbitrary value to an arbitrary address in memory[2]. The safe unlinking check was also added to the kernel pool in Windows 7.
    • Heap entry header cookie: An 8-bit random value was added to the header of each heap entry which is validated when a heap entry is freed. This makes it possible to detect corruption when a chunk is deallocated.

    Windows Vista, Windows Server 2008, and Windows 7

    The heap manager in Windows Vista, Windows Server 2008, and Windows 7 expanded on the hardening work that went into Windows XP SP2 and Windows Server 2003 SP1 by incorporating a number of additional security improvements. These improvements are enabled by default (with the exception of termination on heap corruption) and include:

    • Removal of commonly targeted data structures: Heap data structures such as lookaside lists and array lists, which have been targeted by multiple exploitation techniques, have been removed. Lookaside lists have been replaced by the Low Fragmentation Heap (LFH).
    • Heap entry metadata randomization: The header associated with each heap entry is XORd with a random value in order to protect the integrity of the metadata. The heap manager then unpacks and verifies the integrity of each heap entry prior to operating on it.
    • Expanded role of heap header cookie: The 8-bit random value that is associated with the header of each heap entry has had its scope extended to enable integrity checking of more fields. The cookie’s value is also verified in many more places (rather than only checking at the time that a heap entry is freed).
    • Randomized heap base address: The base address of a heap region is randomized as part of the overall Address Space Layout Randomization (ASLR) implementation and has 5 bits of entropy. This is designed to make the address of heap data structures and heap allocations unpredictable to an attacker.
    • Function pointer encoding: Function pointers (e.g. CommitRoutine) in heap data structures are encoded with a random value to prevent them from being replaced with an untrusted value.
    • Termination on heap corruption: If enabled, any detected corruption of a heap data structure will lead to immediate process termination[1]. This is the default for most built-in Windows applications, and can be enabled dynamically by third parties. If disabled, corruption errors are ignored and the application is allowed to continue executing.
    • Algorithm variation: The allocation algorithms used by the heap manager may shift depending on allocation patterns and policies. This can make it more difficult to deterministically predict the state of the heap when an attack occurs. This may also result in a runtime switch to code paths that have proven thus far to be more resilient to brute force attacks.

    One of the side effects of these changes is that they significantly alter the structure and behavior of the heap. This means that an attacker who is looking to exploit a heap-based vulnerability on Windows XP and Windows Vista will either need to develop a separate exploit for each platform or find a common way to attack the two platforms. These complications increase the level of effort and sophistication required to develop a robust exploit. In addition to the measures that were taken to harden the heap manager itself, Windows Vista, Windows Server 2008, and Windows 7 also include support for DEP and ASLR. These mitigations further complicate the exploitation of any heap related memory corruption vulnerability by making it more difficult for an attacker to execute arbitrary code.

    Heap exploitation techniques

    Techniques that can be used to exploit heap-based memory corruption vulnerabilities have been a hot topic of research in recent years (see references). Most recently, John McDonald and Christopher Valasek from IBM’S ISS X-Force Research team published a comprehensive paper at Black Hat USA 2009 on the topic of heap-based exploitation techniques that apply to Windows XP and Windows Server 2003[13]. Prior to that, Ben Hawkes presented his work on exploitation techniques that could be used against the Windows Vista heap manager[11,12]. Given the significant amount of research that has occurred in this space, we thought that it would be helpful to provide some insight into the impact and relevance of known heap-based exploitation techniques. In the interest of brevity, we will not go into the details of how these techniques work.

    The following table provides a breakdown of the general classes of heap-based exploitation techniques and describes their relevance to Windows Vista, Windows Server 2008, and Windows 7 in terms of their feasibility as currently stated in the literature, perceived degree of difficulty (based on prerequisites), and the specific set of exploit mitigations that are applicable.

    Exploitation technique Targeting Windows Vista, Windows Server 2008, or Windows 7
    Feasible Difficulty Applicable exploit mitigations
    Coalesce unlink overwrite[2,3] No N/A
    • Safe unlinking
    Critical section unlink overwrite[8] No N/A
    • Safe unlinking
    Lookaside list overwrites[4,5,6,14] No N/A
    • Lookaside lists were removed, replaced by LFH
    FreeLists[] attacks[5,6,9,10,11,14]
    Heap cache attacks[14]
    No N/A
    • Array-based FreeLists were removed
      • Invalidates most techniques as stated
    • Safe unlinking
    • Heap entry metadata randomization
    • Heap entry cookie check*
    • DEP & ASLR
    LFH bucket overwrite[13] Yes High
    • DEP & ASLR
    HEAP data structure overwrite[13] Yes High
    • DEP & ASLR
    App-specific data corruption[10,13] Yes Variable
    • If heap entry header corruption is required
      • Heap entry metadata randomization
      • Heap entry cookie check*
    • DEP & ASLR

    How to read this table (using the HEAP data structure overwrite technique as an example): The HEAP data structure overwrite technique is feasible on Windows Vista, Windows Server 2008, and Windows 7 with a high degree of perceived difficulty (due to the prerequisites required in order to make use of it). Even though this technique may be feasible, DEP and ASLR have the potential to further complicate exploitation.

    * If heap metadata randomization material & cookies are secret and terminate on heap corruption is enabled (which is the default for in-box Windows applications and Internet Explorer 7/8).


    The majority of the existing heap-based exploitation techniques that rely on the corruption of heap metadata cannot be used in their current form to exploit heap memory corruption vulnerabilities on Windows Vista and above. This is due to the hardening changes that have been made to the heap manager such as removing commonly targeted data structures, protecting the integrity of heap metadata, and making the state of the heap non-deterministic. While new attacks have been proposed[13], we are not currently aware of any public exploits targeting Windows Vista and above that rely on heap metadata corruption to exploit a real-world heap memory corruption vulnerability. With that said, we expect that heap-based exploitation techniques will continue to be an active research topic. As such, we will continue to investigate heap enhancements (such as those included in RobustHeap) that will make it more difficult for attackers to reliably exploit heap-based memory corruption vulnerabilities.

    - Matt Miller, MSEC Security Science

    *Postings are provided "AS IS" with no warranties, and confers no rights.*


    [1] Michael Howard. Corrupted Heap Termination Redux. June, 2008.
    [2] Solar Designer. JPEG COM Marker Processing Vulnerability in Netscape Browsers. Bugtraq. Jul, 2000.
    [3] Halvar Flake. Third Generation Exploitation. Black Hat Windows Briefings 2002. Feb, 2002.
    [4] Alexander Anisimov. Defeating Microsoft Windows XP SP2 Heap protection. 2004.
    [5] Matt Conover, Oded Horovitz. Reliable Windows Heap Exploits. CanSecWest. 2004.
    [6] Matt Conover. Windows Heap Exploitation (Win2KSP0 through WinXPSP2). SyScan. 2004.
    [7] David Litchfield. Windows Heap Overflows. Black Hat USA. 2004.
    [8] Nicolas Falliere. A new way to bypass Windows heap protections. Sep, 2005.
    [9] Brett Moore. Exploiting FreeList[0] on Windows XP Service Pack 2. Dec, 2005.
    [10] Nicolas Waisman. Understanding and Bypassing Windows Heap Protection. Jul, 2007.
    [11] Brett Moore. Heaps About Heaps. SyScan 2008. Jul, 2008.
    [12] Ben Hawkes. Attacking the Vista Heap. Black Hat USA. Aug, 2008.
    [13] Ben Hawkes. Attacking the Vista Heap. Ruxcon. Nov, 2008.
    [14] John McDonald and Christopher Valasek. Practical Windows XPSP3/2003 Heap Exploitation. Black Hat USA. Jul, 2009.

    Update: Slight clarification made to the exploitation technique table.