Security Research & Defense

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

January, 2009

  • Stack overflow (stack exhaustion) not the same as stack buffer overflow

    Periodically we get reports into the MSRC of stack exhaustion in client-side applications such as Internet Explorer, Word, etc. These are valid stability bugs that, fortunately, do not lead to an exploitable condition by itself (no potential for elevation of privilege). We wanted to clarify the distinction between stack exhaustion and stack buffer overflow. Stack buffer overflows often lead to elevation of privilege. Unfortunately, the literature tends to use stack overflow to refer to both cases, hence the confusion. The error code STATUS_STACK_BUFFER_OVERRUN (0xc0000409) refers to a stack buffer overflow while the error code STATUS_STACK_OVERFLOW (0xc00000fd) refers to stack exhaustion.

    On Bugtraq this morning, there was a public post of a stack exhaustion bug that, fortunately, does not lead to arbitrary code execution. Let's take a closer look at it and a few other examples. We'll start with today's Bugtraq posting:

    <INPUT type="text" name="A" value="CCCCCCCCCCCCCCCCCCCC(many thousands)”>

    When IE attempts to parse this HTML, it runs out of stack space. Hooking up Windbg, you will observe the following first-chance exception:

    (f9c.5b8): Stack overflow - code c00000fd (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000000 ebx=0337304c ecx=09410040 edx=0007c3c0 esi=00000000 edi=0346b800
    eip=77f66627 esp=03373000 ebp=03373000 iopl=0         nv up ei pl nz na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
    77f66627 56              push    esi

    The stack is simply exhausted and there is no possibility of running arbitrary code in this case. Let’s look at a few others.

    The next issue was also reported in IE recently:

    foo = new Array();
    while(true) {foo = new Array(foo).sort();}

    Again, the HTML has requested an extra-ordinary amount of stack space. IE attempts to allocate space and it eventually runs out. Unable to process the HTML, it returns a stack overflow / exhaustion error (0xc00000fd).

    One last example is from April 2008 and, again, it leads to a stack overflow/exhaustion error (0xc00000fd):

    var str = "aaaaaaaaaaaaaaa(many thousands)”
    document.myform.text.value = str
    <form name='myform'>
    <input name='text' type='text' />
    <input name='Submit' type='submit' />

    As you can see, there are several ways of reaching a stack exhaustion condition. Fortunately, these are stability issues that by themselves cannot lead to remote code execution. This happens when a parsing client-side application cannot allocate enough stack space to complete an operation (as shown in the examples here where a web page was attempting to allocate as much stack as possible and eventually runs out of space).

    We are always happy to triage bugs sent to Please send them in to us. We are definitely committed to engineering and security excellence. We evaluate every report and determine whether to service them as security issues or whether to hand them off to the product team to fix as reliability and stability issues. For each security issues, we will triage against the SDL bug bar (link to sample bug bar) and address via the MSRC security bulletin process. All issues (such as these stack exhaustion bugs) that are stability or reliability issues are triaged according to customer impact and addressed in future releases of the product.

    Update Jan 29: Thanks to Mark Dowd for pointing out that stack exhaustion bugs might have a security impact if combined with a buffer overrun bug. You can read more about his research at

    - Jonathan Ness, SVRD blogger

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


    STATUS_STACK_OVERFLOW (0xc00000fd ):

  • MS09-001: Prioritizing the deployment of the SMB bulletin

    This month we released an update for SMB that addresses three vulnerabilities. This blog post provides additional information that might help prioritize the deployment of this update, and help explain the risk for code execution.

    In the bulletin you will see that the cumulative severity rating is Critical for Windows 2000, XP and Server 2003 systems, while Vista and Server 2008 have cumulative severity ratings of Moderate.

    Two of the three vulnerabilities pose the risk for Remote Code Execution (CVE-2008-4834 and CVE-2008-4835), and hence these are rated Critical. However, Vista and Server 2008 systems are not vulnerable to the first of these vulnerabilities, and the second vulnerability does not affect systems using default settings. As a result, we rated Vista and Server 2008 as Moderate for CVE-2008-4835. CVE-2008-4114 affects all Windows platforms and results in a system DoS without any risk of RCE, and hence is rated Moderate. The table below summarizes the exposure for each version of Windows.

    Windows 2000
    Windows XP
    Windows Server 2003
    Windows Vista
    Windows Server 2008

    For all affected versions of Windows, the two RCE vulnerabilities are unlikely to result in functioning exploit code as stated in the exploitability index ( There are a few reasons for this:

    • The vulnerabilities cause a fixed value (zero) to be written to kernel memory – not data that the attacker controls.
    • Controlling what data is overwritten is difficult. To exploit this type of kernel buffer overrun, an attacker typically needs to be able to predict the layout and contents of memory. The memory layout of the targeted machine will depend on various factors such as the physical characteristics (RAM, CPUs) of the system, system load, other SMB requests it is processing, etc.

    In terms of prioritizing the deployment of this update, we recommend updating SMB servers and Domain Controllers immediately since a system DoS would have a high impact. Other configurations should be assessed based on the role of the machine. For example, non-critical workstations could be considered lower priority assuming a system DoS is an acceptable risk. Systems with SMB blocked at the host firewall could also be updated more slowly.

    - Mark Wodrich, SVRD Blogger

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

  • XSS Filter Improvements in IE8 RC1

    On Monday IE8 RC1 was released. Here are some of the most interesting improvements and bug fixes to the XSS Filter feature:

    • Some byte sequences enabled the filter to be bypassed, depending on system locale

      URLs containing certain byte sequences bypassed the Beta 2 filter implementation in some locales. For example, with a Chinese locale system, URLs of the following format would bypass the filter:<script>alert();</script>

      The filter decodes the URLEncoding prior to passing the URL through our regular expression engine. The presence of a raw 0xA0 byte followed by a 0x3C byte (“<”) can cause MultiByteToWideChar to fail. This is because with Chinese and other locales, 0XA0 0x3C is not a valid multi-byte character. In this circumstance, the failure cascades so that the regular expression matching would fail to be case-insensitive. But even worse, at a later point in the regular expression code, the 0xA0 0x3C sequence would be interpreted as a single multi-byte character. Thus the < character would essentially be missing from input and the appropriate heuristic would not detect XSS.

      The IE8 RC1 fix enables the regular expression code to treat all input as a stream of individual bytes, not characters in the default codepage (which could be multi-byte).

      Yosuke Hasegawa and 80sec both discovered this bug in the IE8 Beta 2 release.

    • NULLs in HTTP responses caused filtering to drop chunks of HTTP response data

      The relevant buffer class was rev’d in the code to fix this.

    • Added protection against attack scenarios involving PHP stripslashes

      The stripslashes function in PHP removes backslashes from input. (It also replaces double-backslashes with a single backslash.) It’s common for PHP developers to call stripslashes before outputting a string. In these cases if the output enables a server-side XSS bug, that bug can still be abused despite the IE8 XSS Filter.

      This is an example of a platform-specific artifact as discussed in the XSS Filter Architectural Overview:

      The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.

      This describes the new behavior well – the filter now generates additional signatures as necessary for an alternate interpretation of the input. These new signatures are designed to compensate for the behavior of the PHP stripslashes feature.

      It does appear that the PHP “magic quotes” feature is now deprecated. If the use of stripslashes in PHP code is due to the magic quotes feature then it should be expected that stripslashes usage will decline on the web. Regardless, we made the call that this issue still seems to be pervasive enough, at least today, to be worth mitigating in IE8 RC1.

      Ronald van den Heetkamp identified this issue.

    • Added protection against attack scenarios involving servers that still support overlong UTF-8

      Similar to the PHP Stripslashes change described above, we now generate and process additional signatures if overlong UTF-8 sequences are identified on input.

      While overlong UTF-8 appears to be specifically banned in RFC 3629, it still unfortunately seems to be common enough on web server platforms that it makes sense for us to address this attack vector in our code.

      Amit Klein provided feedback which helped identify this issue.

    • Added protection against attack scenarios involving injection of FORM and ISINDEX elements

      Though in general we do not block generic HTML injection, we make an exception for these two elements as they enable attack scenarios similar to those involving injection of script.

      Gareth Heyes identified the ISINDEX element.

    • OBJECT tag’s CODETYPE attribute is now treated equally to the TYPE attribute

      The OBJECT tag’s CODETYPE attribute provides the same functionality as the TYPE attribute. In IE8 RC1 both attributes are considered equal.

      Gareth Heyes identified this issue.

    • General performance improvements

      Ex: Pre-validation to avoid the performance hit of a regular expression in some cases.

    I want to especially thank Dany Joly on the IE team for the extraordinary work he’s done perfecting the XSS Filter implementation in IE8.

    Onward to RTM!

    David Ross, MSRC Engineering - working on a Security Science project

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

    Update - 2/11/09: Change to blog signature