Security Research & Defense

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

October, 2008

  • More detail about MS08-067, the out-of-band netapi32.dll security update

    Today Microsoft released a security update that fixes a remote code execution vulnerability in the Windows Server Service. This is a serious vulnerability and we have seen targeted attacks using this vulnerability to compromise fully-patched Windows XP and Windows Server 2003 computers so we have released the fix "out of band" (not on the regular Patch Tuesday). Due to the serious nature of the vulnerability and the threat landscape requiring an out-of-band release, you probably have questions about your own organization's risk level, what actions you can take to protect yourself, and why newer platforms are at reduced risk. We hope to answer those questions in this blog post.

    Which platforms are at higher risk?

    An unauthenticated attacker can trigger this vulnerability remotely for code execution on Windows Server 2000, Windows XP and Windows 2003. By default, Windows Vista and Windows Server 2008 require authentication. However, the attacker must be able to reach the RPC interface to exploit the vulnerability. In the default out-of-the-box scenario, the interface is not reachable due to the Windows firewall enabled by default on Windows XP SP2, Windows Vista, and Windows Server 2008. Unfortunately, either one of the following two conditions exposes the RPC endpoint:

    1) Windows firewall is disabled
    2) Windows firewall is enabled but file/printer sharing is also enabled.

    When File/Printer Sharing is enabled on Windows Vista and Windows Server 2008, the Windows firewall only expose the RPC interface to the network type shared. For example, if a printer is shared on a network type ‘Private’, the Windows firewall will block incoming RPC connections if the computer switches over to a network type ‘Public’. If you then choose to share the printer on the network type ‘Public’, Vista and Windows Server 2008 will prompt to ask if you really want to enable “File and Printer Sharing” for ALL public networks.

    For more information about file/printer sharing, visit the following URLs:

    - for Vista http://technet.microsoft.com/en-us/library/bb727037.aspx
    - for XP http://www.microsoft.com/windowsxp/using/security/learnmore/sp2firewall.mspx

    The following picture illustrates the risk for each platform in more detail.

    More about mitigations (DEP, ASLR, /GS)

    On Vista and Windows Server 2008, the combination of Address Space Layout Randomization (ASLR, http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx) and Data Execution Protection (DEP, http://support.microsoft.com/kb/875352/EN-US/ ) will make the exploitation of this vulnerability more difficult. ASLR will randomize the base address of modules, heaps, stacks, PEB, TEBs, etc. making difficult the return into known locations. Known DEP bypass techniques will not be applicable on these platforms because of the presence of ASLR.

    Regarding /GS protection, the stack frame of the function that contained the overflowed buffer was protected with a stack frame boundary cookie. However, due to the nature of this particular vulnerability, the exploit code is able to take advantage of another stack frame that was not meant to be protected by the /GS security cookie. The /GS security cookie is only emitted for functions meeting certain criteria.

    UAC mitigates even when the prompting is disabled

    As mentioned above, Windows Vista and Windows Server 2008 by default require authentication. But the security callback on the RPC interface has not been changed on the more recent platforms. Instead, the UAC and integrity level hardening work introduced with Vista is forcing the authentication requirement. The anonymous user connects with integrity level "Untrusted" while the named pipe requires at least a "Low" integrity level. Since "Untrusted" is lower than "Low" integrity level, the access check fails. Note that disabling the UAC prompt does not disable the integrity level access check. In other words, regardless of whether the UAC prompt is enabled or disabled, the integrity level check will be performed. The integrity level check will fail on Vista and Windows Server 2008 if the user connects anonymously. See http://msdn.microsoft.com/en-us/library/bb625963.aspx for more information.

    There is a non-default scenario where a non-domain-joined Windows Vista and Windows Server 2008 can be exploited anonymously. If the feature “Password Protected Sharing�� is disabled, anonymous connections come in at “Medium” integrity level. Because "Medium" integrity level is a higher integrity level than "Low", the integrity level check will succeed. This would allow Windows Vista and Windows Server 2008 to be exploited anonymously. This feature could be disabled through Vista’s Network Sharing Center in the “Sharing and Discovery” section.

    Most perimeter firewalls will block exploit attempts from outside your organization

    If you are behind a perimeter firewall that filters inbound connections to TCP ports 139 and 445, you will not be reachable from the Internet. This is a common home user scenario. In this scenario, only the machines in your local LAN will have the ability to exploit this vulnerability.

    How you can protect yourself

    You should apply the security update as soon as you can. This is the best way you can protect yourself. While you are testing the update and preparing your deployment process, you may choose to use one or more of the workarounds listed in the security bulletin. (http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx) We have researched several options that range from turning off the affected component to limiting the exposure to authenticated users.

    There is one other workaround option that we didn't include in the bulletin because it is not a supported scenario. The Server service exposes the vulnerable code over an RPC named pipe. The access control list for the named pipe is specified in the netapi32.dll code. It can be changed for any current Windows session. When Windows is rebooted, the ACL will get reset to the default value. However, if you were to change the ACL on every boot after the service is started, the window of attack for anonymous users would be very small. We have developed a simple tool that can remove the ANONYMOUS access control entry is the named pipe's access control list. (Please remember that this is not a supported scenario.) Here's what it looks like when run:

    C:\>chacl.exe \\.\pipe\srvsvc
    opening up \\.\pipe\srvsvc
    Got back 3 ACE entries
    Found an entry for ANONYMOUS LOGON. Deleting it...
    deleted that ACE
    
    Setting new DACL changes...
    Done
    
    C:\>chacl.exe \\.\pipe\browser
    opening up \\.\pipe\browser
    Got back 3 ACE entries
    Found an entry for ANONYMOUS LOGON. Deleting it...
    deleted that ACE
    
    Setting new DACL changes...
    Done
    

    We have attached the chacl.c source code at the bottom of this blog post.

    Greetz

    A great deal of investigation in a short amount of time went into this case. We'd like to publicly thank all the engineers who helped provide definitive answers (some requiring hours of debugging) to these hard technical questions.

    - Bruce Dang, Fermin J. Serna, Damian Hasse, Andrew Roths and Jonathan Ness from the SVRD team
    - Matt Miller and other members from the Microsoft Security Engineering Science Team
    - David Kruse from the core filesystem team
    - Tassaduq Basu and Raghu Gatta from the Windows Networking team
    - Jon Schwartz from the Windows kernel team
    - Carlos Trueba Salinas from the Windows Sustained Engineering team

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

  • MS08-061 : The case of the kernel mode double-fetch

    MS08-061 addresses several vulnerabilities in win32k.sys where you can execute arbitrary code in kernel mode. These bugs can only be exploited locally and there is no remote vector based on our investigation of the vulnerability.

    One of these vulnerabilities involves multiple kernel mode accesses of user mode data leading to an interesting race condition.  When accessing user mode data, kernel mode code needs to “capture” a copy of the user mode data locally and avoid accessing the user mode original multiple times.  Failing to do so results in a type of problem known as a “double fetch”.

    When the kernel captures the user mode data, it works with the local copy (located in kernel address space) and is not affected by any changes that happen to the user mode copy. This capture avoids race conditions involving different values of the data being returned from subsequent user mode fetches.

    A double fetch from user mode could lead to several security vulnerabilities.  In the case of MS08-061, we are addressing an inadequate pool allocation and a later memory pool overflow.  Let’s look at a piece of the vulnerable source code:

    // Attacker controls lParam
    void win32k_entry_point(...) {
       […]
          // lParam has already passed successfully the ProbeForRead
    
          my_struct = (PMY_STRUCT)lParam;
          if (my_struct ->lpData) {
               cbCapture = sizeof(MY_STRUCT) + my_struct->cbData;  // [1] first fetch 
        […]
                     // my_struct ->lpData has already passed successfully the ProbeForRead
        […]
                if ( my_allocation = UserAllocPoolWithQuota(cbCapture, TAG_SMS_CAPTURE)) != NULL) {   
                     RtlCopyMemory(my_allocation, my_struct->lpData, my_struct->cbData);   // [2] second fetch 
                }
          }
       […]
    }
    

    As you can see in the above vulnerable code, there are two fetches of the same user mode data ([1] and [2]). Since the kernel cannot guarantee that both fetches will have the same value, a small allocation can occur in [1] but later in [2] the kernel copies the data with a bigger length causing a memory pool overflow. This can easily be performed with a parallel, and high priority, thread changing the supplied address range (pointed by lParam) in a loop.

    A kernel developer should keep these issues in mind and should capture whatever data the code is using from user mode avoiding double fetches.

    // Attacker controls lParam
    void win32k_entry_point(...) {
      […]
         // lParam has already passed successfully the ProbeForRead
              
         my_struct = (PMY_STRUCT)lParam;
         cbData_captured= my_struct->cbData;
         lpData_captured = my_struct->lpData;
         if (lpData_captured) {
             cbCapture = sizeof(MY_STRUCT) + cbData_captured;  
            
        […]
             // lpData_captured has already passed successfully the ProbeForRead
        […]
    
             if ( my_allocation = UserAllocPoolWithQuota(cbCapture, TAG_SMS_CAPTURE)) != NULL) {   
                 RtlCopyMemory(my_allocation, lpData_captured, cbData_captured);   
             }
          }
        […]
    }
    

    - Fermin J. Serna, SVRD Blogger

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

  • Service isolation explanation

    The past few days, we have had service isolation on our minds here in Redmond after the POC code posting last week from Cesar Cerrudo.  Nazim Lala from the IIS team posted a great blog entry about the fix and why it is taking so long to release it.  I expect it to be close to the amount of code churn as XP SP2.  We’re backporting a huge amount of infrastructure work from the Vista servicing hardening effort back down-level.  It’s really a monumental amount of work for a security update.  Nazim's blog entry goes into more detail.

    But I wanted to make sure everyone knew what set of customers are at risk.  I think Cesar outlined it pretty well but just to recap: an attacker would need to be executing code in the context of a Windows service to use this exploit.  More precisely, an attacker needs the SeImpersonatePrivilege privilege in their token in order to start the privilege escalation. 

    IIS is a good attack vector in scenarios where a hosting provider hosts untrusted code.  Cesar also points out the SQL Server scenario where a SQL DBA has admin rights to the database but not on the machine running the database.  There might be other attack vectors as well.  You can investigate any potential attack vectors in your scenario by checking the token in any process running code from untrusted sources.  The easiest way to do so is via Process Explorer.  Double-click on any running process and click the “Security” tab to see the options.  Here are a couple examples.

    Svchost running as NETWORK SERVICE:

    cmd.exe running as an unprivileged user:

    To recap, the vulnerable scenario is as follows:

    1 – Process token has SeImpersonatePrivilege privilege
    2 – Process is running at privilege level less than SYSTEM (otherwise, no escalation)
    3 – Process runs untrusted code or allows untrusted users to execute code

    If your network fits this criteria, we strongly encourage you to review Security Advisory 951306 and apply the workarounds listed. 

    - Jonathan Ness, SVRD Blogger

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

  • MS08-059 : Running Microsoft Host Integration Server 2006 as non-admin

    Microsoft Host Integration Server 2006 is an interesting product.  It allows developers to manage business processes on IBM mainframe and AS/400 (big iron) servers as XML web services.  You can find a free trial version available for download at http://www.microsoft.com/hiserver/downloads/default.mspx.

    Unfortunately, access to the management interface was not properly locked-down.  MS08-059 is an update for Microsoft Host Integration Server 2006 which secures the SNA RPC service interface.  It is possible for an attacker to run code remotely and take control of a Microsoft Host Integration Server 2006 if this update is not installed.  The update adds better RPC user verification as well as locking down some of the unneeded remote management functionality exposed by this interface.

    If you use Microsoft’s Host Integration Server 2006 in your environment, it’s important that you secure the servers running HIS as soon as possible.  Our first recommendation, of course, is to apply the security update as soon as possible.  If you cannot apply the update right away (it does require a reboot), there are a couple things you can do to limit your exposure to any potential attacks abusing this vulnerability.

    One temporary workaround is to use the Service Control Manager to disable the SNA RPC service, and prevent it from starting automatically.  This will prevent the vulnerable service from running, but will also prevent remote management.  Firewalling the RPC port is not a valid workaround, since the port used for communicating is dynamically assigned when the service starts.

    One thing you could do to limit risk is to run the service as a lower-privileged user.  Any successful attacks would then run at a reduced privilege, hopefully limiting the extent of the damage.  We already recommend this during installation by displaying a pop-up warning (see screenshot below).  We also mention this in documentation, but some people might have missed that so we’re emphasizing this option in this blog post.  Running under a non-administrator account reduces potential risks and will limit exposure of the vulnerable interface.

    - SVRD Bloggers

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

  • MS08-066 : Catching and fixing a ProbeForRead / ProbeForWrite bypass

    The driver afd.sys is responsible for handling socket connections.  MS08-066 addresses several vulnerabilities in afd.sys that could allow an attacker to execute arbitrary code in kernel mode. These vulnerabilities can only be exploited locally and there is no remote vector from our investigations.

    One of these vulnerabilities involves a ProbeForRead / ProbeForWrite bypass when using user supplied memory pointers and lengths.  We have blogged before about ways to bypass these functions and how to protect your drivers from these vulnerabilities.  In that post, we talked about an attacker bypassing checks by using a zero length.  The update today is a new type of bypass in that the driver does not validate the entire range passed in.

    Let's look at some piece of source code:

    // Attacker controls OutputBuffer and OutputBufferLength
    void IOCTL_handler(...) {
    [...]
            try {
                ProbeForWrite (OutputBuffer,
                                    OutputBufferLength, //  [1] length could be zero and this will be bypassed even with a kernel mode address
                                    sizeof (UCHAR));
    
                RtlCopyMemory(
                    OutputBuffer,
                    (PUCHAR)context+endpoint->Common.VcConnecting.RemoteSocketAddressOffset,
                    endpoint->Common.VcConnecting.RemoteSocketAddressLength  // [2] copy based on a non-zero value to a kernel mode address
                    );
    
            } except( AFD_EXCEPTION_FILTER(&status) ) {
            
            }
    [...]
    }
    
    

    The vulnerability in the above could happen when the driver validates a range of memory to be inside user mode address space but later uses a different range for copying. In this case, an attacker can supply the range (addr=kernelmode, size=0) bypassing the ProbeForWrite check as we can see at [1], but the driver will later use (addr=kernelmode,endpoint->Common.VcConnecting.RemoteSocketAddressLength) writing to a kernel mode address as we can see at [2].

    A security minded kernel developer could fix this in such a way validating OutputBufferLength and using it twice.

    void IOCTL_handler(...) {
    [...]
             if (OutPutBufferLength!=endpoint->Common.VcConnecting.RemoteSocketAddressLength) {
                 //bail out... 
                 return;
             }
             try {           
    
                ProbeForWrite (OutputBuffer,
                                    OutputBufferLength, 
                                    sizeof (UCHAR));
                RtlCopyMemory(
                    OutputBuffer,
                    (PUCHAR)context+endpoint->Common.VcConnecting.RemoteSocketAddressOffset,
                    OutPutBufferLength  
                    );
    
             } except( AFD_EXCEPTION_FILTER(&status) ) {
            
             }
    [...]
    }
    

    Part of our MSRC process is to look for variations in the area of each reported vulnerability and give feedback to the engineering groups so our future code does not contain these issues.  In this case, we applied three parallel strategies:

    1 – Fuzzed the IOCTL handlers
    2 – Applied binary static analysis tools on top of phoenix
    3 – Source code review of the area

    We hope this blog post helps you understand MS08-066 and gives you an idea of what to look out for in your code.

    - Fermin J. Serna, SVRD Blogger

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

  • Most common questions that we've been asked regarding MS08-067

    Since the release we have received several great questions regarding MS08-067 (http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx), thus we decided to compile answers for them. We still want to encourage everyone to apply the update.

     

    Can the vulnerability be reached through RPC over HTTP?

    No, the vulnerability cannot be reached through RPC over HTTP. RPC over HTTP is an end-to-end protocol that has three roles: client, proxy and server. To be clear, this is different from standard RPC, and the two protocols do not interoperate. Moreover, the only way to hit the vulnerable code is through named pipes, so the Interface security callback will drop the connection when connecting through TCP/IP.

    Using Outlook to connect to an Exchange server to access e-mail is a common scenario that uses RPC over HTTP; since the RPC over HTTP proxy is used the Exchange server is not exposed to external attacks.

     

    Further information about RPC over HTTP:

    http://msdn.microsoft.com/en-us/library/aa375384.aspx

    Further information about using Exchange with RPC over HTTP:

    http://technet.microsoft.com/en-us/library/aa996072(EXCHG.65).aspx

     

     

    What type of protections does ISA provide against this vulnerability?

      1. The ISA and TMG RPC filter only recognizes RPC traffic that begins on the RPC End-Point Mapper (TCP:135). Since MS08-067 attacks are carried within CIFS (TCP:445) or NetBIOS (TCP:139) connections, they are not visible to the ISA or TMG RPC filter.
      2. By default, ISA Server and TMG do not allow RPC, NetBIOS or SMB traffic from the external network.
      3. By default, ISA 2000 allows all traffic unfiltered from the LAT (internal network) to the local host.  The update should be applied to any ISA 2000 deployment immediately.
      4. By default, ISA 2004, 2006 and TMG do not allow SMB, NetBIOS Session or RPC to the local machine except from remote management hosts, array members and Content Storage Servers (CSS).  Since compromised CSS and remote management hosts may pose a threat to the ISA or TMG server, they should have the update applied immediately.
      5. If you have changed ISA or TMG policies to allow SMB or NetBIOS traffic to the local host (such as for a Branch Office scenario), you should apply the update to your ISA or TMG server immediately.

     

    Can an anonymous user reach the vulnerable code if the “restrict anonymous named pipes” group policy setting is used?

    There are two different behaviors depending on the platform version.

    Unfortunately the Windows XP SP2 and Windows Server 2003 group policy setting “Network Access: Named pipes that can be accessed anonymously” (see http://technet.microsoft.com/en-us/library/cc785123.aspx for more information) will not block anonymous connections to the browser named pipe. The vulnerable code can still be reached since by default, connections to this named pipe will be allowed regardless of the setting. In short, even if “browser” is removed from this list, the named pipe can still be reached anonymously.

    In Windows Vista and Windows Server 2008 this behavior was changed and the setting takes effect when the browser named pipe is removed and the system is restarted.

     

    Would sharing files and/or printers via Terminal Server or Remote Desktop Connection expose the vulnerability?

    No, Terminal Server and Remote Desktop Connection do redirection using virtual channels embedded inside the RDP protocol. Moreover, Terminal Server does not open ports 139 or 445.

     

     

    We would like to thank the engineers who helped provide definitive answers to these technical questions:

    - Bruce Dang, Fermin J. Serna, Damian Hasse, Andrew Roths and Jonathan Ness from the SVRD team

    - Tassaduq Basu, Kamen Moutafov from the Windows Networking Team

    - Scott Field from the Windows Security Architecture Team

    - Jim Harrison from the ISA Team

    - Costin Hagiu from the RDP Team

    - David Kruse from the Core File System Team

     

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

  • Bulletin severity for October bulletins

    Bulletin severity is an interesting topic to many blog readers.  We often hear that you think a bulletin should be rated higher or lower.  Sometimes we even hear one person suggesting a higher rating and another suggesting a lower rating for the same issue.  J  This post is not to advocate for or against the MSRC rating system but we’d just like you to understand what we were thinking for each bulletin.  Our official bug bar is not posted but we pointed to a close approximation of it last month in this blog post (http://blogs.technet.com/swi/archive/2008/09/09/ms08-055-microsoft-security-response-process-behind-the-scenes.aspx).  Direct link is http://msdn.microsoft.com/en-us/library/cc307404.aspx if you want to follow along.

    MS08-057 fixes several Excel vulnerabilities reachable by opening a malformed Excel spreadsheet. This vulnerability is rated Critical for users of Office 2000 because some configurations of Office 2000 do not prompt before opening an XLS file offered via a website.  It is rated Important on the other affected platforms where Excel does display the Open/Save dialog prompt before opening.  This user interaction (clicking through the prompt) lowers the code execution vulnerability from Critical to Important.

    MS08-058 addresses six separate CVE’s in Internet Explorer.  They can be lumped together into three different buckets.

    The first three IE issues each allow cross-domain script execution.  On Windows 2000, a webpage that can execute script in the local machine zone can run arbitrary code.  So that’s a Critical “Remote Code Execution” class vulnerability on Windows 2000.  All other platforms have a feature called “Local Machine Zone Lockdown”.  With LMZ-L enabled, attackers can no longer run script in the local machine zone so there is no direct remote code execution opportunity.  Instead, the risk is Information Disclosure as malicious.com can trick you into posting website cookies for another domain.  Windows Server 2003 and 2008 have both the local machine zone lockdown feature and have enabled the Enhanced Security Configuration by default.  ESC disables scripting.  Without script, cross-domain scripting is not relevant.  If users disabled ESC, this would be an information disclosure threat.  However, because the attack surface is not exposed by default, we drop it down two ratings from “Important” to “Low”.  Each of these three issues are different vulnerabilities.  With CVE-2008-2947, an attacker can force script to execute in the wrong domain context by playing tricks with the location object.  CVE-2008-3472 and CVE-2008-3473 confuse IE into executing script from a different zone through mouse and focus trickery.

    The next vulnerability in the list, CVE-2008-3474, is also a cross domain vulnerability but you probably noticed that this is not rated as a Remote Code Execution Critical vulnerability on Windows 2000. This is a case of malicious.com being allowed to make requests via MSXML from other zones. However, in this case, malicious.com cannot trigger the vulnerability without some help. In fact, to trigger this vulnerability, a victim page must host the malicious page in a frame. The “Important” rating we gave it might be a little bit of a stretch but the advertising hosting model of untrusted content being hosted on trusted pages tipped us over to rating this one Important. Again, the Enhanced Security Configuration on Windows Server 2003 and 2008 mitigates this threat so it is rated two notches lower on those platforms.

    Finally, the last two CVE’s are straight memory corruption issues.  CVE-2008-3475 fixes an issue where a pointer is uninitialized and then used.  CVE-2008-3476 addresses a case of script methods being called out of order in an unexpected manner.   Neither of the issues affects Windows Vista but on Windows 2000 and Windows XP they could result in code execution, “drive-by” class vulnerabilities.  Scripting is disabled by default on Windows Server 2003 and 2008 so the memory corruption issues that require scripting on those platforms drop down two severity notches to “Moderate”.

    MS08-059 addresses a vulnerability in the Host Integration Server RPC service.  One of our team members wrote a great blog post about it [here].

    MS08-060 addresses a remote code execution vulnerability on Windows 2000 domain controllers.  We have rated the bulletin Critical.

    MS08-061 fixes three different win32k.sys (kernel-mode) vulnerabilities involving privilege escalation from an unprivileged local user to ring 0.  Fermin wrote more detail about it [here].

    MS08-062 addresses a vulnerability for which we have seen targeted attacks so we’re very happy to be getting it fixed.  This fixes an issue with the Internet Printing Service, an IIS ISAPI filter that requires authentication in order to reach.  Remote authenticated code execution vulnerabilities rate Important according to the bug bar.

    MS08-063 is remote code execution vulnerability reachable over SMB.  However, an attacker cannot reach the vulnerable code using the null session share so the attacker must be authenticated to exploit this vulnerability.  (or the Guest account must be enabled)  Again, we rate remote authenticated code execution vulnerabilities as “Important”.

    MS08-064 addresses a vulnerability that could allow a local attacker who has logged onto a system to potentially execute code in ring 0.  Local elevation of privilege vulnerabilities are rated Important.

    MS08-065 is rated Important and two team members wrote a blog post that explains it in more detail.  You can read that [here].

    MS08-066 is another local elevation of privilege vulnerability.  It allows a 16-byte memory overwrite to an arbitrary location to local attackers so this one is rated Important.  Fermin wrote more about this vulnerability [here].

    Finally, we also released a security advisory with killbits for several controls.  Releasing killbits via security advisory is something relatively new from Microsoft.  There are two scenarios where we will release a killbit via security advisory instead of a security bulletin.  First, when a Microsoft  control has already been fixed with a previous security bulletin, we will follow on later with a killbit package.  The other scenario is when we issue killbits for 3rd party products.

    Thanks for reading and we hope this gave you a better understanding of the Microsoft bulletin rating system.  Please email us with any questions.  Thanks!

    Update 10/16/2008 - Fixed formatting.  Thanks Frank for pointing it out!

    - Jonathan Ness, SVRD Blogger

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

  • MS08-065 : Exploitable for remote code execution?

    Today, we released MS08-065 to fix an issue in MSMQ.  You’ll notice that the bulletin was rated “Important” and indicates that remote code execution is possible.  However, we would like to show you that in practice the severity of the fixed issue is limited only to information disclosure.

    If the MSMQ service were installed by default on any affected Windows configuration, we would have rated this one Critical.  The “off-by-default” mitigation drops the rating one notch from Critical to Important.  We would like to help you understand the information disclosure threat by revealing some details about the vulnerability. Quick stepping through the pseudo-code representing this issue will give you a sense of whether or not this issue will be exploited in the real-world.

    WCHAR *
    SomeRpcFunction (int ptr)
    {
          ...
          WCHAR *buf = ((blah *) ptr)->SomeString;
          DWORD size = sizeof(WCHAR) * (wcslen(buf) + 1)
          ... do some sanity checking ...
          WCHAR *buf2 = allocatememory(size);
          wcscpy(buf2, buf);
          ...
          return buf2;
    }
    

    The attacker can pass in any address he wants for “ptr” and the function will happily try to dereference it. If the attacker does this correctly, there will be some information leakage through the string returned by the function. For code execution, the attacker has a much tougher job. It will have to be a timing attack. The attacker will need to modify memory (using a separate thread) during the window of time between the string length calculation and the wscpy(). The memory modification would have to make the length of the string bigger than it was when the length of the string was calculated several lines of code earlier. In real world scenarios, we expect that exploiting this race condition in a reliable manner would be very difficult. We can also look at it from an assembly perspective to see the window of attack, measured in assembly instructions:

    6b96ac16 8b780c          mov     edi,dword ptr [eax+0Ch]

    6b96ac19 897de4          mov     dword ptr [ebp-1Ch],edi

    6b96ac1c 57              push    edi

    “edi” is a pointer to a string

    6b96ac1d ff15c0f4996b    call    dword ptr [mqqm!_imp__wcslen (6b99f4c0)]

    We pass it to wsclen(). The calculated string length will be in “eax”)

    6b96ac23 59              pop     ecx

    6b96ac24 8d440002        lea     eax,[eax+eax+2]

    Note the compiler optimization on "eax";this instruction is the same as eax = 2*(eax+1).  “eax” now represents how many bytes we need to store the string)

    6b96ac28 8945e0          mov     dword ptr [ebp-20h],eax

    6b96ac2b 3d00000400      cmp     eax,40000h

    6b96ac30 7615            jbe     mqqm!QMGetRemoteQueueName+0x73 (6b96ac47)

    do some error checking

    6b96ac32 a1dc1b9b6b      mov     eax,dword ptr [mqqm!s_FN (6b9b1bdc)]

    6b96ac37 8945cc          mov     dword ptr [ebp-34h],eax

    6b96ac3a 6899000000      push    99h

    6b96ac3f 50              push    eax

    6b96ac40 be06000ec0      mov     esi,0C00E0006h

    6b96ac45 eb52            jmp     mqqm!QMGetRemoteQueueName+0xc5 (6b96ac99)

    6b96ac47 50              push    eax

    “eax” is how many bytes we needed (see 0x6b96ac24)

    6b96ac48 e88879ffff      call    mqqm!MIDL_user_allocate (6b9625d5)

    We allocate a buffer of size “eax”

    6b96ac4d 8bf0            mov     esi,eax

    Save the ptr in "esi"

    6b96ac4f 8975dc          mov     dword ptr [ebp-24h],esi

    6b96ac52 57              push    edi

    “edi” is the pointer to the string we had before. If the attacker managed to change memory content at this pointer, then the length can be greater than what we calculated before...

    6b96ac53 56              push    esi

    “esi” is our newly allocated buffer

    6b96ac54 ff15c8f4996b    call    dword ptr [mqqm!_imp__wcscpy (6b99f4c8)]

    we do wscpy() on it.  If the length of string at “edi” changed, then we have a buffer overflow

     

    - SVRD Bloggers

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