Security Research & Defense

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

March, 2009

  • Behavior of ActiveX controls embedded in Office documents

    The Microsoft Office applications (Word, Excel, PowerPoint, etc) have built-in ActiveX control support. ActiveX support allows a richer experience when interacting with an Office document. For example, a document author could use the Safe-For-Initialization Office Web Components (OWC) ActiveX control to retrieve data from an intranet data source.

    Office applications’ prompting behavior

    By default, Office applications do not prompt when instantiating a Safe-For-Initialization ActiveX control. This is similar to Internet Explorer’s behavior in the Internet Zone. The main difference between Office and IE is that Office applications such as Word, Excel, or PowerPoint do not care about the ActiveX Safe-For-Scripting setting because they do not have any scripting support besides VBA. If you have malicious VBA code running, you are in big trouble even without using any ActiveX controls.

    Also by default, ActiveX controls not marked as SFI can only be loaded if the user enables it via the prompt. Here is what the prompt looks like:

    How can an attacker abuse this rich experience enabled by Safe-For-Initialization ActiveX controls?

    Attackers have discovered ActiveX support in Office applications and have been using it to more effectively lure victims to web-based malware. They have recently used the “Microsoft Scriptlet Component” to navigate victims to a website exploiting a patched Internet Explorer vulnerability (CVE 2009-0075, fixed by security bulletin MS09-002). Seems like attackers have discovered it is easier to trick a user to open a Word document attached to email compared to luring a user to click a dubious-looking link. This specific attack is mentioned in a Trend Malware Blog posting last week (http://blog.trendmicro.com/another-exploit-targets-ie7-bug//).

    Let’s take a closer look at this Scriptlet ActiveX control:

    Clsid: {ae24fdae-03c6-11d1-8b76-0080c744f389}
    Progid: ScriptBridge.ScriptBridge.1
    Binary Path: C:\Windows\system32\mshtml.dll
    Implements IObjectSafety: True
    Safe For Initialization (IObjectSafety): True  ****
    Safe For Scripting (IObjectSafety): True
    Safe For Initialization (Registry): False  
    Safe For Scripting (Registry): False
    KillBitted: False
    

    Because this ActiveX control is marked as SFI, an Office document can use it without showing any prompt, similar to what IE does by default in Internet Zone. This is the “by design” behavior. (We explain how you can get this information about any ActiveX control registered on your system in this SRD blog post from Feb 2008.)

    How to configure ActiveX support in Office

    If you are concerned about Safe-for-Initialization ActiveX controls being instantiated by Office without prompt, you can configure this behavior in Office 2007. Here is a screenshot from the Office 2007 Trust Center:

    Office’s help Topic “Enable or disable ActiveX controls in Office documents“ gives a detail explanation about ActiveX configuration. It describes the default “Prompt me before enabling all controls with minimal restrictions” to be the settings described above:

    • If the document contains VBA, all ActiveX controls are disabled by default. Office would prompt the user, asking if he/she wants to enable the Active control.
    • If the document contains no VBA
      • ActiveX controls marked as SFI (Safe for initialization) would be loaded without any prompt.
      • ActiveX controls not marked as SFI can only be loaded if the user enables it via the prompt.
    • Office honors the IE’s Killbit setting. If an ActiveX control has been kill-bitted, it will not be loaded.

    If you do not want any ActiveX controls to be used by Office documents, you could change the setting to be “Disable all controls without notification”. The ActiveX setting in the trust center can also be set via group policy or registry. For more information, please refer to the following links:

    Office 2007: “Security policies and settings in the 2007 Office system

    Office 2003/XP: “How Policies Work” and Microsoft Knowledge Base article 827742.

    Chengyun, MSRC Engineering

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

  • CanSecWest Preview & New Blog URL

    It’s getting busy around here with people preparing for the CanSecWest security conference (http://cansecwest.com/). Many of the Microsoft Security Engineering Center (MSEC) and Microsoft Security Response Center (MSRC) members that regularly post to this blog will be attending CanSecWest and soaking up the 3 days of presentations & networking.

    If you haven’t heard us talk about the Security Science angle of MSEC before, let me explain. The Security Science team is a group of security experts who do applied security research to solve difficult, leading-edge problems in an effort to increase customer security. They do research into new ways of finding vulnerabilities, develop innovative exploit mitigation techniques, and provide tracking and early warning of exploitation events. The team is literally in the same hallways as the MSRC, so the type of problems they tackle spring directly from current vulnerability cases and exploits. After they successfully crack a problem the tools and methods that result are reviewed for inclusion into the Security Development Lifecycle (SDL). This is one of the ways we move the SDL forward and keep it current.

    The Security Science team aims to find ways to do security smarter and then enable others to leverage that work. So we’ve submitted a few talks to CanSecWest that will highlight the work that MSEC does:

    1. The Evolution of Microsoft's Exploit Mitigations [Tim Burrell, Matt Miller]. This is a view into the exploit mitigations work the Security Science team does. It’ll show what we’ve done, why we’ve done it and how we systematically think about mitigations coverage. We’ll also reveal a mitigation enhancement that will be in a beta release soon.
    2. Automated Real-time and Post Mortem Security Crash Analysis and Categorization [Jason Shirk, Dave Weinstein]. We know developers can’t all be security experts and properly triage exploitability conditions, so the difficulty is to get tools to reliably diagnose issues for security impact without a security expert present. This presentation will demonstrate a tool we use internally, and will soon be sharing with the security researcher & developer communities.

    Final time slots haven’t been assigned yet, so check back at the CanSecWest site.

    Matt Miller is also queuing up to do a Lightning Talk on High Signal to Noise Vulnerability Detection, so watch for us there as well.

    New Blog URL

    As we announced in a previous blog post, we have expanded the focus of this blog to include Security Science work.  To eliminate confusion and better align with the actual blog title, we updated the url to better reflect this change.  The blog url is now http://blogs.technet.com/srd/

    For those who have this bookmarked or are receiving RSS feeds, this will be seamless for you as the old url/feeds redirect to the new ones.  Nevertheless we wanted to provide you with a heads-up. 

    See you in Vancouver!

    Matt Thomlinson

    Senior Director, TwC Security

    Share this post :

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

  • Assessing the risk of the schannel.dll vulnerability (MS09-007)

    MS09-007 resolves an issue in which an attacker may be able to log onto an SSL protected server which is configured to use certificate based client authentication with only the public key component of a certificate, not the associated private key. Only a subset of customers who log into SSL protected servers are at risk but it is a little tricky to explain who might be affected due to the unique nature of this vulnerability. This blog entry will help you assess the risk to which your application is exposed by explaining those details.

    Affected deployments

    This vulnerability does not apply to customers who have mapped certificate-authenticated users against an Active Directory domain. It only applies in those situations where certificates are mapped to local Windows accounts on the server. For domain deployments, we still recommend applying the update as a defense in depth measure.

    Customers can find more information on the different ways of certificate mapping here: http://technet.microsoft.com/en-us/library/cc736706.aspx

    The vulnerability

    In a PKI deployment, digital X.509 certificates contain a public key component, which can be distributed to other parties that allows them to encrypt data that only the holder of the corresponding private key can read. When web sites use certificates for client authentication, they generally require the user to encrypt certain data with his private key to prove that he is really the owner of the certificate used to authenticate. This specific vulnerability occurs due to a flaw in the way the server validates that the user is using his private key to authenticate. As such, in some circumstances a user may successfully authenticate by only providing the public key, and not using the corresponding private key.

    Determining if your configuration is at risk

    On the Windows client platform, certificates are stored in the certificate store under the user’s individual account. Each certificate has an “Intended purpose” assigned. Common Intended purposes include Secure Email, Client Authentication, Encrypting File System, and All Intended Purposes. These describe for what purpose applications on the Windows client can use a specific certificate. A certificate can have multiple purposes. These intended purposes cannot be changed by the user, but are part of the EKU extension of the digital certificate. They are read-only and set by the certificate issuer.

    You can review the intended purpose(s) of your certificates by clicking Start, and running “certmgr.msc”, the Microsoft Management Console certificate snap-in. The “Intended Purpose” shows under Personal, then Certificates, as seen in the screenshot below:

    Your configuration would not be at significant risk unless an attacker gets access to your user’s public keys. While the public key component of a certificate is a “public key”, it’s important to understand that when a user authenticates against an SSL protected IIS web server, the public key component of the certificate is not transferred in clear text. During the authentication process, it cannot be sniffed off the wire by an attacker on the local subnet. As such, if the certificate is configured with an intended purpose of “Client Authentication” only, it would be more difficult for an attacker to gain access to the certificate and exploit the vulnerability. He would need to gain access to the certificate on the machine, or convince the user to authenticate against his own, malicious web site.

    This deployment scenario is most common in those situations where the owner of a web site himself issues certificates to his users, and can limit the uses to a specific purpose. Another potentially impacted scenario is when the owner of a protected SSL web site allows users to use their own generic certificates to authenticate against a server. In this case, the user may also be using the certificate for other purposes (i.e. the certificate may have multiple intended purposes), such as authenticating against wireless networks or signing e-mail. Depending on the purpose, the public key may be distributed in clear text and to untrusted parties. This would make it easier for an attacker to gain access to the victim’s public key which he needs to exploit this vulnerability successfully, and thus increases the risk significantly.

    We hope this blog entry helps address some of the questions you may have, and helps you assess the risk this vulnerability poses to your web application and its users.

    - Maarten Van Horenbeeck (MSRC Operations), Robert Hensing and Jonathan Ness (MSRC Engineering)

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

  • MS09-008: DNS and WINS Server Security Update in More Detail

    After releasing security update MS09-008, we received a number of questions on the WPAD issue (CVE-2009-0093) addressed in the update. There are claims that this update is ineffective. Let me be clear that this update will protect you and it should be deployed as soon as possible. Below is an overview on how the complete security update helps protect a system.

    This security update resolves a number of different vulnerabilities with different attack vectors:

    1. DNS Server Query Validation Vulnerability (CVE-2009-0233)
    2. DNS Server Response Validation Vulnerability (CVE-2009-0234)
    3. DNS Server Vulnerability in WPAD Registration (CVE-2009-0093)
    4. WPAD WINS Server Registration Vulnerability (CVE-2009-0094)

    We’ll review these in a bit more depth starting with the validation vulnerabilities and afterwards looking in more depth at the WPAD registration issue that has attracted most questions.

    DNS Server Query and Response Validation Vulnerabilities

    CVE-2009-0233 and CVE-2009-0234 are two vulnerabilities that allow an attacker to successfully spoof DNS responses by issuing specifically crafted DNS queries.

    A DNS transaction ID is a number that uniquely identifies a single DNS transaction. The DNS server uses it to identify if a response to a query is in fact legitimate. When transaction IDs are predictable, an attacker could spoof valid responses to DNS queries made by the server, and as such introduce arbitrary addresses into the DNS cache.

    In both vulnerabilities, the server does not cache specific types of DNS responses, allowing an attacker to cause the DNS server to continuously request a specific Resource Record (RR). This makes it easier for an attacker to match the correct transaction ID and source port combination and successfully spoof a response. The security update resolves these two issues by improving the way the DNS server will cache and re-use answers to these specific types of queries.

    DNS Server Vulnerability in WPAD Registration

    CVE-2009-0093 describes an issue with how the Web Proxy Auto-Discovery, or WPAD, and the Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP, can be abused by an attacker.

    This is typically a local domain attack where there is a degree of trust between the domain members. The Windows DNS server can allow clients to register their own hostname in the DNS server using dynamic updates. In the most common scenario, this takes place using secure dynamic updates, where a client authenticated against the domain can update its own name on the DNS server. If the WPAD or ISATAP names have not yet been registered, a domain-authenticated user could register his own machine as either of these two names.

    The reason why ISATAP and WPAD are so interesting for an attacker to register, is because they are default names a client will resolve to obtain specific functionality. In the case of WPAD, the name tells the host where to connect for proxy configuration information. In the case of ISATAP, it points to a tunneling server that connects IPv6 hosts over IPv4 networks.

    WPAD in particular is common enterprise functionality, and as such Microsoft needs to be very careful when releasing a security update to ensure that we both protect our customers, and do not break the functionality they have come to rely upon.

    The security update we released helps protect customers by implementing a block list on the DNS server, containing a list of names which the DNS server will no longer resolve. This list is implemented as the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\

    GlobalQueryBlockList

    (3/18/09: Updated registry key)

    If the WPAD and ISATAP names are not registered on the DNS server when the security update is installed this block list is populated with both names. When a client issues a query for one of those names the DNS server will return a negative response, even if an attacker registers it.

    However, when a DNS server already has an entry for either WPAD or ISATAP before the update is applied, it will not add that name to the block list, and will continue to answer requests for them. As an example, if a DNS server has a resource record configured named WPAD, the security update will add only the name ISATAP to the block list. If a DNS server does not have WPAD nor ISATAP configured, the block list will contain both names.

    This is necessary as many of our customers legitimately use this functionality. Implementing a block list that blocks these names in all cases, requiring the administrator to remove them manually would break these configurations.

    One concern that was raised by a security researcher is that an attacker may have introduced a malicious WPAD entry through a dynamic DNS update. When you install the security update after such an attack has taken place, the WPAD name will not be added to the block list, and the attack will continue to be effective.

    This is indeed not a scenario the security update, or any security update released by Microsoft aims to address. Security updates are intended to help protect the system against future exploitation, and don’t aim to undo any attack that has taken place in the past. The update does not actively change the current configuration. When installing the update, it has no way of knowing whether the WPAD entry was configured by an administrator or an attacker.

    Customers who have this specific concern can validate the IP address assigned to the current WPAD/ISATAP entries in their DNS zones using the DNS MMC snap-in:

    1. Open the DNS MMC snap-in from the Administrative tools group
    2. Expand “Forward Lookup Zones”
    3. For each zone, look for Host (A), IPv6 address (AAAA) or Alias (CNAME) records with a name of ‘WPAD’ or ‘ISATAP’:

    clip_image002

    In addition, KB article 968732 describes in detail how a DNS administrator can manually edit the DNS block list to suit his environment.

    WPAD WINS Server Registration Vulnerability

    CVE-2009-0094 covers the same attack as the DNS Server Vulnerability in WPAD Registration, but using WINS. A WPAD-configured client can look up a host by resolving the name WPAD in WINS as opposed to DNS. This security update will install a WINS block list which is, as with DNS, pre-populated with the WPAD, “WPAD.” and ISATAP names, unless that name is present in the current WINS database. The WINS block list is implemented as the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\
    Parameters\QueryBlockList

    Customers can validate whether a WPAD name is currently registered in their WINS database using the WINS MMC snap-in:

    1. Open the WINS MMC snap-in from the Administrative tools group
    2. Right click on "Active Registrations" and choose "Display records"
    3. On the "Record Mapping" tab check the "Filter records matching this name pattern" and type "wpad"

    Any active WPAD name registrations should show in the "Active Registrations" window as shown below:

    clip_image002[6]

    KB article 968731 describes in detail how a WINS administrator can edit the WINS block list. Note that the WINS block list is independent from the DNS block list, and in both cases block lists do not replicate across multiple servers.

    Beyond the two issues we’ve address regarding the WPAD protocol with this update, there may be other ways clients could get redirected to WPAD servers unintentionally. We’re continuing to investigate these. In fact, guidance around this can be found here http://www.microsoft.com/technet/security/advisory/945713.mspx.

    We hope this blog entry clarifies the content of the security update and answers any questions you may have. This security update addresses a number of vulnerabilities and we recommend installing it at your earliest convenience.

    -Maarten Van Horenbeeck, MSRC Program Manager

    We’d like to thank the following contributors to this blog:

    • Robert Hensing, MSRC Engineering
    • Bruce Dang, MSRC Engineering
    • Jeff Westhead, Windows Core Networking
    • Shyam Seshadri, Windows Core Networking

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

    Share :

    3/18/09 Update: Fixed error in the DNS registry key. Thanks to Daniel A Baillargeon for bringing this to our attention.

  • GS cookie protection – effectiveness and limitations

    The Microsoft C/C++ compiler supports the GS switch which aims to detect stack buffer overruns at runtime and terminate the process, thus in most cases preventing an attacker from gaining control of the vulnerable machine.  This post will not go into detail about how GS works, so it may be helpful to refer to these MSDN articles for an overview and loads of detail on how GS works and what a GS cookie is. It’s important to note that depending on the exact vulnerability, even if a function is protected by a GS cookie, a stack-based buffer overrun may still be exploitable – for example if the attacker can gain control prior to the cookie check. However even in these circumstances, GS can often be a significant obstacle to exploitation and/or reliability of exploitation. There have been some stack-based attacks recently that were not mitigated by GS – this post takes a couple of examples and looks at why that was.

    This companion post looks at how Visual Studio 2010 improves GS in light of some of the limitations covered in this post.

    MS08-067 – netapi32 vulnerability in parsing path name

    In MS08-067 (see also associated SDL blog entry), there is a fixed size buffer on the stack and the vulnerability is in the code that parses the path for “\..” substrings, replacing them with the explicit directory name as required. For example \\server\A\B\C\..\D\..\..\E” would be resolved to “\\server\A\E”. The vulnerability lies in the fact that when searching backwards through the path string buffer for a ‘\’ character the pointer returned by this search can sometimes end up being before the start of the path buffer.

    Let’s look at how this key fact impacts the effectiveness of GS when data is then copied into memory starting at that address. The call stack looks like:

    netapi32!ConvertPathMacros+0x101
    netapi32!CanonicalizePathName+0x102

    The path string buffer is defined in CanonicalizePathNames and that function is GS-protected. The ConvertPathMacros function is not GS-protected: it takes a pointer to the path buffer defined in CanonicalizePathNames as one of its arguments and has itself no local variables that would lead to it being GS-protected.

    The initial stack layout is as below, with the ConvertPathMacros function having a pointer to the pathBuffer variable defined in CanonicalizePathName:

    image

    Step 1: the search for ‘\’ character causes a pointer to reference address before the start of path buffer.

    image

    Step 2: attacker-controlled data is then written starting at that address, overwriting ConvertPathMacro’s stack frame data:

    image

    Step 3: ConvertPathMacro function returns, but its return address has been overwritten so that the attacker gains control. In the diagram above the GS cookie in CanonicalizePathName is not overwritten. Note that it is irrelevant whether the overflow overwrote the GS cookie in CanonicalizePathName or not: this is because the cookie in CanonicalizePathName’s stack frame is only checked when CanonicalizePathName returns. And the attacker gains control long before that, when ConvertPathMacros returns.

    This is an example of a stack-based vulnerability and attack that GS is simply not designed to mitigate: GS will only protect against an overflow if:

    1. The cookie is overwritten as part of the overflow.

    2. The cookie check at function return is reached.

    In this example neither of the two criteria above need apply.

    MS07-017 – ANI file parsing vulnerability

    By way of contrast, compare this with the ANI vulnerability in MS07-017 (see also associated SDL blog entry). The corresponding call stack was:

     

    user32!ReadChunk
    user32!LoadAniIcon

    ReadChunk was effectively just copying data from the ANI file to a pointer provided by LoadAniIcon. The attacker could not control this pointer so exploiting MS07-017 could not be achieved by overwriting ReadChunk’s stack frame as in the previous case. However the LoadAniIcon function where the buffer vulnerable to overflow was defined was not GS-protected at all! So a traditional overflow targeting LoadAniIcon’s return address was feasible.

    image

    The ANIHEADER local variable overflowed in the ANI vulnerability was a pure data structure:

    typedef struct _ANIHEADER {
    DWORD cbSizeof;
    DWORD cFrames;
    DWORD cSteps;
    DWORD cx, cy;
    DWORD cBitCount, cPlanes;
    DWORD jifRate;
    DWORD fl; } ANIHEADER, *PANIHEADER;

    The compiler uses a heuristic to decide which functions to GS-protect, and this is targeted mainly at protecting against string buffer overflows. As LoadAniIcon contained no such string buffers then it was not GS-protected.

    Unlike the previous example then, the ANI vulnerability could in principle have been mitigated by GS, if GS were applied more extensively; eg if LoadAniIcon had been GS-protected then the picture would have looked like:

    image

    The overflow would have overwritten the GS cookie and when LoadAniIcon returned then the GS cookie check would have detected the overflow and terminated the process. As noted at the start, depending on the exact control flow in LoadAniIcon between the overflow and the cookie check at function exit it may still be possible to exploit this; however GS has removed the generic method of exploitation making any exploit harder to develop and (experience tells us) often far less reliable.

    It turns out that there is a way of instructing the compiler to be more aggressive in what functions it GS-protects via a pragma: #pragma strict_gs_check (blogged about here by Mike Howard). In fact partly as a result of this ANI vulnerability, MSEC worked with product teams in Windows to apply the strict GS pragma to a number of parser components as part of Windows Vista Service Pack 1.

    Summary

    GS is designed to mitigate a specific class of stack-based attacks, making stack-based exploits harder to develop, less reliable, and in some cases reducing what would have been attacker code execution to a denial-of-service. For example at the time of writing, we do not know of an exploit for MS06-040 on Windows XP SP2+ or Windows Server 2003 SP1 platforms. The SDL requires all Microsoft products to be built with GS enabled. Many third-party products use GS too – including recent versions of Quicktime, Adobe Acrobat, and Flash for example.

    Where the attacker has more fine-grained control of where to start the overflow, or the direction of an overflow/underflow then the GS mitigation won’t help. In some cases however GS would help if present, and its absence is purely related to the default heuristics that the compiler uses. For high-risk code – code that handles untrusted data for example – consider making use of the strict_gs_check pragma.

    Looking ahead I’m also excited at the prospect of “Enhanced GS” – what’s “Enhanced GS”? Well, it’s a whole other article: check back here over the next couple of days and read all about it!

    And of course there is no substitute for the code being secure in the first place!

    - Tim Burrell, MSEC Security Science

    Links to related articles

    /GS (Buffer Security Check), MSDN Visual C++ compiler options entry

    Compiler Security Checks in Depth, MSDN Visual Studio Technical Articles, Brandon Bray, February 2002

    MS08-067 and the SDL, SDL blog entry, Michael Howard, October 2008

    Lessons learned from the Animated Cursor Security Bug, SDL blog entry, Michael Howard , April 2007

    Hardening stack-based buffer overrun detection in VC2005 SP1, Michael Howard’s blog, April 2007

    #pragma strict_gs_check , MSDN C/C++ pre-processor reference.

  • Enhanced GS in Visual Studio 2010

    In a previous post we noted some stack-based vulnerabilities, such as MS08-067, that GS was not designed to mitigate due to the degree of control available to an attacker. However, other vulnerabilities such as the ANI parsing vulnerability in MS07-017 would have been mitigated if the GS cookie protection had been applied more broadly. The strict_gs_check pragma was mentioned as one way of achieving broader coverage.

    One downside of the strict GS heuristic is that it is very aggressive. It will GS protect any function that has an address-taken local variable (even an address-taken integer). MSEC undertook some basic code analysis and identified that a number of functions currently protected with a GS cookie were actually provably safe. The idea was born to give GS an overhaul as part of the Visual Studio 2010 release – Enhanced GS:

    1. Enhancing the GS heuristic to consider a greater scope of local variables worthy of protection

    2. Implement a new optimization that would remove cookies identified as unnecessary.

    Any cookie increase is bound to lead to performance questions due both to the direct overhead of the extra cookie checks and indirect impact on inlining other aspects of code generation and optimization. The goal was for the resulting scheme to be applicable system-wide – as for the original GS work – rather than be a targeted approach such as the strict_gs_check code pragma.

    Enhanced GS heuristic in Visual Studio 2010

    The highest priority was to update the heuristic to protect data structures such as the ANIHEADER structure in MS07-017. There have been other security bulletins where pure data structures such as these have been overflowed. For example consider the structure involved in the Office Publisher vulnerability in MS06-054:

    typedef struct _STTBF
    {
      ulong bMax;
      ulong ibstMac;
      ulong reserved3;
      ulong cbExtra;
      uchar fNoShrink;
      uchar wReserved2;
      ushort wReserved;
    } STTBF;

    Protecting all structures would likely be too expensive in terms of the number of extra cookies that would result. We decided to increase the scope of the structures that GS would treat as potentially vulnerable to only those structures that contained no members of a pointer type. It seems less likely that a component would read in a pointer value to local memory from an untrusted file, compared to it reading document/media or some other kind of data. Thus the ANI structure in the previous post and the STTBF Publisher structure above are both covered by the enhanced GS heuristic in Visual Studio 2010. However a structure defined as follows is not:

    typedef struct _MYSTRUCT
    { 
      int bMin;
      int bMax;
      int bAverage;
      void *pSomePointer
    } MYSTRUCT;

    In a similar vein, whereas the legacy GS heuristic only protects arrays where the element size is 1 or 2 bytes (such as chars and wchars), the Visual Studio 2010 enhanced GS heuristic protects any kind of array as long as the element type is not of pointer type.

    char myStringBuffer[256]; // protected
    DWORD myIPAddresses[256]; // protected
    HANDLE myPointerTable[256]; // not protected

    There are also a number of additional criteria: an array needs to have more than 2 elements in order to qualify, any structure including an array of the kind described above would be protected, and so on. However, the two examples above capture the main new cases that the enhanced GS heuristic is designed to cover.

    It is also worth mentioning that any variable considered as potentially vulnerable under the legacy GS heuristic is also considered potentially vulnerable under the new heuristic. By carefully designing the heuristic around past security bulletin history and in tandem with performance measurements from internal product teams in Microsoft, we believe this to be truly deployable as an application-wide mitigation.

    Enhanced GS optimization in Visual Studio 2010

    Just because a variable (due to its type or size) is considered potentially vulnerable does not mean that its use will necessarily lead to a vulnerability! This insight has led to a new compiler optimization that is planned for Visual Studio 2010. Specifically, the new optimization recognizes instances of safe variable usage and suppresses GS cookie emission in such instances.

    For example the code snippet below would normally lead to the function being GS protected due to the presence of a character buffer.

    STDAPI ConsumeData(BYTE *pbData)
    {
      BYTE Temp[MAX];
    
      if (pbData)
      {
        ...
        memcpy (Temp,
                pbData,
                ARRAYSIZE(Temp));
        ...
    }

    Analysis of the use of the Temp buffer makes it clear that it can never be overflowed: its only use is in a memcpy instruction, and the number of bytes copied is bounded by the size of the array. In this case, the function does not need to be GS protected and as such can be safely optimized away.

    Summary

    Visual Studio 2010 introduces an enhanced GS heuristic that provides significant security improvements by increasing the scope of GS protection to a carefully targeted superset of those functions protected by the legacy GS scheme.

    Of course the compiler change is just the first step. Any application developed using VS2010 is set to benefit from the improved security provided by enhanced GS. Inside Microsoft, MSEC have already started to work with several product teams so that once Visual Studio 2010 has shipped then they can start migrating their future releases to the updated compiler and take advantage of the enhanced GS capability. In the meantime, try out the upcoming Visual Studio 2010 beta and let us know what you think!

    Links to related articles

    MS08-067 and the SDL, SDL blog entry, Michael Howard, October 2008

    Lessons learned from the Animated Cursor Security Bug, SDL blog entry, Michael Howard, April 2007

    Hardening stack-based buffer overrun detection in VC2005 SP1, Michael Howard’s blog, April 2007

    #pragma strict_gs_check , MSDN C/C++ pre-processor reference.

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

  • Released build of Internet Explorer 8 blocks Dowd/Sotirov ASLR+DEP .NET bypass

    Last summer at BlackHat Vegas, Alexander Sotirov and Mark Dowd outlined several clever ways to bypass the Windows Vista defense-in-depth protection combination of DEP and ASLR in attacks targeting Internet Explorer. One approach they presented allowed attackers to use .NET framework DLL’s to allocate executable pages of memory at predictable locations within the iexplore.exe process. They were then able to demonstrate how .NET behavior could be combined with a separate exploitable memory corruption vulnerability to run arbitrary code. It was actually pretty brilliant. You can find the paper here.

    We are always learning from the security community. The feedback we receive from the community is invaluable. It is usually a different view of our products that we can use to help protect customers. Last week, the IE team launched IE8 with an interesting mitigation that comes directly from the security community's feedback. The final release of Internet Explorer 8 on Windows Vista blocks the .NET DEP+ASLR bypass mechanism from malicious websites on the Internet. Specifically, IE8 created a new URLAction that regulates loading of the .NET MIME filter. By default, the URLAction prevents it from loading in the Internet and Restricted Sites Zones. The .NET MIME filter is allowed to load by default in the Intranet Zone.

    IE8 is pretty cool technology. We have been using it internally now for a while. One of the great things about it is the layering of defenses on top of defenses. No browser is 100% secure but we are hoping if we keep adding defenses they will be harder and harder to exploit. We heard from security researchers and exploit writers at both CanSecWest last week and SOURCE Boston the week before that writing exploits for Windows Vista is “very, very hard” with all these mitigations to work around. We expect that blocking the .NET DEP+ASLR bypass will make it even harder.

    We have smart engineers thinking all day every day about mitigations and testing ways to bypass our defense-in-depth approach to security. If you have an idea that you'd like to share, please email us at switech _at_ microsoft.com. Thanks!

    - Jonathan Ness, MSRC Engineering

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

  • New EMF gdiplus.dll crash not exploitable for code execution

    Yesterday we noticed a blog post and securityfocus article about a potential new vulnerability in Microsoft GDI+ when parsing a specially-crafted EMF file. You might have heard about it referred to as ‘GpFont.SetData()’. We wanted to address some speculation about this EMF parsing bug.

    First, our initial investigation shows that it is not exploitable for code execution. We are still investigating all the potential ways to hit this code but in all the common cases so far, our /GS mitigation is an effective defense-in-depth measure. The EMF parsing bug ends up writing 0x0000, a single Unicode 0 character, over the lower two bytes of the /GS security cookie. Only those two bytes are overwritten and the application is terminated due to the /GS failure.

    Here’s where the issue occurs:

    0:000> k
    ChildEBP RetAddr  
    0007e37c 4ec9e783 gdiplus!GpFont::SetData+0x6a
    0007e3a0 4ec9e70f gdiplus!MetafilePlayer::AddObject+0x8f
    0007e3b4 4ec9d1b5 gdiplus!ObjectEPR::Play+0x1a
    0007e3d0 4ec9ce34 gdiplus!GdipPlayMetafileRecordCallback+0x35
    0007e3fc 4ec9cd4e gdiplus!MetafilePlayer::EnumerateEmfPlusRecords+0x66
    0007e414 77f2072f gdiplus!EnumEmfWithDownLevel+0x52
    0007e490 4ec9e625 gdi32!bInternalPlayEMF+0x707 
    0007edd4 4eca0c90 gdiplus!MetafilePlayer::EnumerateEmfRecords+0xd7
    0007ee70 4ec9e67f gdiplus!GpGraphics::EnumEmfPlusDual+0x27d
    0007ef90 4ed03350 gdiplus!GpMetafile::EnumerateForPlayback+0x686
    0007efc0 4ec9bb58 gdiplus!GpMetafile::Play+0x26
    

    The gdiplus!GpFont::SetData code shows an obvious off-by-one bug.  This was subsequently fixed before Vista shipped.  Here’s the Windows XP code:

    #define FamilyNameMax 32
    ...
    WCHAR familyName[FamilyNameMax];
    ...
     length = fontData->Length; // this comes from the EMF file
    ...
    if (length > FamilyNameMax)
    {
     length = FamilyNameMax;
    }
    ...
    // read in the familyName/data
    UnicodeStringCopyCount (familyName, (WCHAR *)dataBuffer, length);
    familyName[length]=0;

    Here’s what it looks like from the assembly:

    gdiplus!GpFont::SetData:
    4ecff9e9 8bff            mov     edi,edi
    4ecff9eb 55              push    ebp
    4ecff9ec 8bec            mov     ebp,esp
    4ecff9ee 83ec44          sub     esp,44h
    4ecff9f1 a10000dd4e      mov     eax,dword ptr [gdiplus!__security_cookie (4edd0000)] ds:0023:4edd0000=00006ea3 
    4ecff9f6 53              push    ebx
    4ecff9f7 8945fc          mov     dword ptr [ebp-4],eax // Security cookie saved in ebp-4
    4ecff9fa 8b4508          mov     eax,dword ptr [ebp+8]
    

    You can see from the top of the function that the security cookie is 00006ea3. Now let's look lower.

    4ecffa29 8b4804          mov     ecx,dword ptr [eax+4]
    4ecffa2c 894f10          mov     dword ptr [edi+10h],ecx
    4ecffa2f 8b4808          mov     ecx,dword ptr [eax+8]
    4ecffa32 894f18          mov     dword ptr [edi+18h],ecx
    4ecffa35 8b480c          mov     ecx,dword ptr [eax+0Ch]
    4ecffa38 894f14          mov     dword ptr [edi+14h],ecx
    4ecffa3b 8b7014          mov     esi,dword ptr [eax+14h]
    4ecffa3e 8d4c3618        lea     ecx,[esi+esi+18h]
    4ecffa42 83c018          add     eax,18h
    4ecffa45 394d0c          cmp     dword ptr [ebp+0Ch],ecx
    4ecffa48 0f8283000000    jb      gdiplus!GpFont::SetData+0xe8 (4ecffad1)
    4ecffa4e 83fe20          cmp     esi,20h
    4ecffa51 7603            jbe     gdiplus!GpFont::SetData+0x6d (4ecffa56)
    4ecffa53 6a20            push    20h
    4ecffa55 5e              pop     esi
    4ecffa56 56              push    esi
    4ecffa57 50              push    eax
    4ecffa58 8d45bc          lea     eax,[ebp-44h] //0x20 WCHAR buffer
    4ecffa5b 50              push    eax
    4ecffa5c e8d7750600      call    gdiplus!GpRuntime::UnicodeStringCopyCount (4ed67038)
    4ecffa61 a15009dd4e      mov     eax,dword ptr [gdiplus!Globals::FontCollection (4edd0950)]
    4ecffa66 66895c75bc      mov     word ptr [ebp+esi*2-44h],bx 
    4ecffa6b 8b7008          mov     esi,dword ptr [eax+8]
    4ecffa6e 395e08          cmp     dword ptr [esi+8],ebx
    

    If we break in just before that string copy, we see the following:

    eax=00913658 ebx=00000000 ecx=00000020 edx=05aa010c esi=00000020 edi=0091c798
    eip=4ecffa66 esp=0007e32c ebp=0007e37c iopl=0         nv up ei pl zr na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
    gdiplus!GpFont::SetData+0x7d:
    4ecffa66 66895c75bc      mov     word ptr [ebp+esi*2-44h],bx ss:0023:0007e378=6ea3 
    

    Remember from the assembly above that the security cookie was 00006ea3. Here’s how memory looks before the mov instruction:

    0:000> dd ebp-0x10
    0007e36c  44332211 001d0b0b 44332211 00006ea3
    0007e37c  0007e3a0 4ec9e783 05aa00b4 00000024
    0007e38c  0091e008 0091e008 00000030 0091e001
    0007e39c  0091e008 0007e3b4 4ec9e70f 00000000
    0007e3ac  05aa00b4 00000024 0007e3d0 4ec9d1b5
    0007e3bc  0091e008 00004008 00000600 00000024
    0007e3cc  05aa00a8 0007e3fc 4ec9ce34 00004008
    0007e3dc  00000600 00000024 05aa00b4 0091e008
    

    You can see the cookie on the stack protecting the return address. And then after the copy it is overwritten:

    0:000> dd ebp-0x10
    0007e36c  44332211 001d0b0b 44332211 00000000
    0007e37c  0007e3a0 4ec9e783 05aa00b4 00000024
    0007e38c  0091e008 0091e008 00000030 0091e001
    0007e39c  0091e008 0007e3b4 4ec9e70f 00000000
    0007e3ac  05aa00b4 00000024 0007e3d0 4ec9d1b5
    0007e3bc  0091e008 00004008 00000600 00000024
    0007e3cc  05aa00a8 0007e3fc 4ec9ce34 00004008
    0007e3dc  00000600 00000024 05aa00b4 0091e008
    

    As always, we encourage responsible disclosure of potential vulnerabilities. Best way to get ahold of us is secure@microsoft.com. Thanks.

    - Jonathan Ness, MSRC Engineering

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