Security Research & Defense

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

August, 2010

  • An update on the DLL-preloading remote attack vector

    Last week, we released Security Advisory 2269637 notifying customers of a publicly disclosed remote attack vector to a class of vulnerabilities affecting applications that load dynamic-link libraries (DLL’s) in an insecure manner. At that time, we also released a tool to help protect systems by disallowing unsafe DLL-loading behavior.

    Today we wanted to provide an update by answering several questions we have received from customers and addressing common misperceptions about the risk posed by this class of vulnerability.

    • The user experience of the exploit in progress
    • The dangers of untrusted, Internet-zone WebDAV
    • Enabling the CWDIllegalInDllSearch protection tool

    The user experience of the exploit in progress

    This class of vulnerabilities does not enable a “driveby” or “browse-and-get-owned” 0-click attack. To be exploited, a victim would need to browse to a malicious WebDAV server or a malicious SMB server and double-click a file in the Windows Explorer window that the malicious server displays. Let’s walk through an example of what an attack might look like:

    First, the user browses to a malicious website:

    The website would then attempt to display a new Windows Explorer window that points to a malicious WebDAV or SMB share. On systems running Protected Mode, Internet Explorer will require user consent to launch Windows Explorer, using a security warning like the one below. Protected Mode is enabled by default for Internet Explorer on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

    After the user allows Windows Explorer to launch (or if they have previously requested that Internet Explorer no longer display this warning), the user will be presented with a Windows Explorer dialog that is likely to look like the one below:

    At this point, if the user were to double-click the data file on the share, the affected application could potentially run attacker code that is separately hosted on the same WebDAV server.

    The dangers of untrusted, Internet-zone WebDAV

    As described above, this class of vulnerabilities could allow malicious code to run if an attacker can convince a victim to do the following:

    • Browse to a malicious, untrusted WebDAV server in the Internet Zone; and
    • Double-click a file that appears by its extension and icon to be safe

    Unfortunately, based on attack patterns we have seen in recent years, we believe it is no longer safe to browse to a malicious, untrusted WebDAV server in the Internet Zone and double-click on any type of files. Attackers are clever, substituting dangerous file icons with safe, trusted file icons. They have even recently begun obfuscating the filename based on character encoding tricks (such as right-to-left character encoding). Their goal is to entice unsuspecting users into double-clicking on a malicious executable. With or without this new remote vector to the DLL Preloading issue, it’s very hard to make a trust decision given the amount of control an attacker has over the malicious WebDAV server browsing experience. We recommend users only double-click on file icons from WebDAV shares known to be trusted, safe, and not under the control of a malicious attacker.

    Enabling the CWDIllegalInDllSearch protection tool

    We have received several questions regarding the best way to enable the protection tool released on the Microsoft Download Center last week.

    First, you should know that downloading and installing the tool alone will not protect a workstation from vulnerable applications. It ships “off-by-default” and must be enabled either system-wide or for specific applications. After releasing this tool, we received a number of questions on how best to deploy it. We have now updated the KB article to address them. We encourage you to review the updated knowledge base article 2264107.

    Secondly, customers have asked us to recommend the best setting among the three choices. We recommend one of two settings, depending on the specific risk about which you are concerned.

    • Setting the CWDIllegalInDllSearch regkey to 2 system-wide will completely block any network-based attack. We’ve built an automated Fix-it solution to enable that. You can click the Fix-it graphic below on systems that have already installed the tool to set CWDIllegalInDllSearch = 2, blocking DLL loads from the current working directory for both WebDAV and SMB except in cases where the application is run from a WebDAV or SMB share.

    Note: The Fix-it itself does not install the workaround tool. You’ll need to separately download and install the tool beforehand.

    • To instead completely block all DLL-preloading attack vectors, including the threat of malicious files on a USB thumb drive or files arriving via email as a ZIP attachment, set CWDIllegalInDllSearch to 0xFFFFFFFF. This will address any DLL preloading vulnerabilities that may exist in applications running on your system. However, it may have some unintended consequences for applications that require this behavior, so we do recommend thorough testing.

    This section option can be enabled by following these steps:

    • Install the tool from KB2264107.
    • Log on to your computer as an administrator.
    • Open Registry Editor.
    • Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
    • Right-click Session Manager, point to New, and then click Dword Value.
    • Type CWDIllegalInDllSearch, and then click Modify.
    • In the Value data box, type 0xFFFFFFFF, and then click OK.

    While the impact of the above change seems to be low, a reader of this blog wrote in that he experienced a compatibility issue with the Outlook 2002 address book. If you experience issues such as this, they can be mitigated by setting a special policy for the affected binaries that overrides the default CWDIllegalInDllSearch. The following steps show how to do this for OUTLOOK.EXE:

    • Log on to your computer as an administrator.
    • Open Registry Editor.
    • Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\OUTLOOK.EXE
    • If a key with the application binary name does not exist, then you will have to create one.
    • Right-click OUTLOOK.EXE, point to New, and then click Dword Value.
    • Type CWDIllegalInDllSearch,and then click Modify.
    • In the Value data box, type 2, and then click OK.

    This will still prevent OUTLOOK.EXE from loading DLL’s from a remote network share or WebDAV location, but it does not remove CWD from the library search path for this application altogether. This process can be repeated for all other applications that may no longer work correctly. As discussed, we don’t believe this will be common, but we do recommend testing.

    Thanks for your interest in this issue. Please send questions in to switech@microsoft.com.

    Jonathan Ness, MSRC Engineering
    Maarten Van Horenbeeck, MSRC Program Manager

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

  • More information about the DLL Preloading remote attack vector

    Today we released Security Advisory 2269637 notifying customers of a remote attack vector to a class of vulnerabilities affecting applications that load DLL’s in an insecure manner. The root cause of this issue has been understood by developers for some time. However, last week researchers published a remote attack vector for these issues, whereas in the past, these issues were generally considered to be local and relatively low impact. In this blog post, we’d like to share:

    • Background about the vulnerability
    • Information to help you make a risk assessment for your environment
    • An optional binary update you can install to protect your systems
    • Guidance for developers
    • What Microsoft is doing

    The vulnerability

    When an application loads a DLL without specifying a fully qualified path name, Windows will attempt to locate the DLL by searching a defined set of directories. We have discussed the DLL search path on this blog and it has also been explained well on David LeBlanc’s blog. For the sake of this issue, its sufficient to say that if an attacker can cause an application to LoadLibrary() while the application’s current directory is set to an attacker-controlled directory, the application will run the attacker's code. Development best practices state that applications should call SetDllDirectory with a blank path before calling LoadLibrary(“foo.dll”) to ensure that foo.dll is not loaded from the current directory. We are investigating whether any of our own applications are affected by this class of vulnerability so that we can take appropriate action to protect customers.

    Making a risk assessment for your environment

    The most likely exploit scenario involves an attacker convincing the victim to open a file hosted on an attacker-controlled SMB or WebDAV share. The file itself would not necessarily be malicious or malformed. The key is that the file is loaded from a location where an attacker can also place a malicious DLL with the same name as a DLL the vulnerable application loads.

    If a perimeter firewall prevents a system from making outbound SMB or WebDAV connections to attacker-controlled locations, this issue poses little risk. An attack cannot be automatically launched through email or web browsing attack vectors; a user must choose to open a file. However we recognize that users will often open trusted filetypes. We continue to recommend that all outbound SMB is filtered at the perimeter firewall. In addition, the security advisory recommends disabling the WebDAV client service on workstations to prevent outbound WebDAV connections.

    A tool you can use to protect your systems

    Another option for protecting your systems is to deploy a tool that can help prevent exploitation of this issue. Knowledge Base article 2264107 offers for download a tool that allows customers to selectively change the library loading behavior, either system-wide or for specific applications.

    Customers can set the following two registry keys: 

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
    Session Manager\CWDIllegalInDllSearch
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\
    Image File Execution Options\binaryname.exe\CWDIllegalInDllSearch

    Setting the first key will define the system-wide behavior, whereas the second key will set the behavior for one particular application. Note that this is an Image File Execution Option (IFEO), and thus will be valid for all binaries with that same name on the system.

    The values for these keys have slightly different effects, depending on from where the application is started.

    Scenario 1: The application is started from a local folder, such as C:\Program Files

    0xffffffff Removes the current working directory from the default DLL search order.
    0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
    1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
    2 Blocks a DLL load from the current working directory if the current working directory is set to a remote folder.

    Scenario 2: The application is started from a remote folder, such as \\remote\share

    0xffffffff Removes the current working directory from the default DLL search order.
    0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
    1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
    2 Allows DLL load from the current working directory if the current working directory is set to a remote folder.  DLL's that are loaded from a WebDAV share are blocked if the current working directory is set to a WebDAV share.

    Scenario 3: The application is started from a WebDAV folder, such as http://remote/share

    0xffffffff Removes the current working directory from the default DLL search order.
    0 Uses the default DLL search path. This is the Windows default, and the least secure setting.

    How can developers address these issues?

    Microsoft recommends that developers clearly define from where they intend to load specific libraries. This was documented in the specific LoadLibrary application programming interface documentation on MSDN. However, we recognize that this guidance may not always have been very clear. We recently published an MSDN article, “Dynamic-Link Library Security,” that provides specific guidance to developers on how to load these libraries securely.

    While there are several affected situations, described in detail in the above MSDN article, our general recommendations are:

    • Where possible, use a fully qualified path name when loading a library;
    • Remove the current directory from the search path by using SetDLLDirectory;
    • Do not use SearchPath to locate a library. SearchPath was not intended to look for libraries to be loaded into the application process space, and uses an insecure search order;
    • Do not attempt to load libraries purely to identify the version of Windows. Instead, use GetVersionEx or a similar function offered by the Windows API.

    We’ve also recently drafted additional guidance to help developers understand this issue. You can find that developer guidance attached to the blog post

    What Microsoft is doing

    Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future.

    Microsoft is also conducting a thorough investigation into how this new vector may affect Microsoft products.  As always, if we find this issue affects any of our products, we will address them appropriately.

    We hope this blog helps address any questions you may have. Thanks to Mark Debenham, Anoop KV, Hari Pulapaka, Dou Kaya, Gov Maharaj, David LeBlanc, and Michael Howard for their work on this issue.

    Cheers,

    Jonathan Ness, MSRC Engineering
    Maarten Van Horenbeeck, MSRC Program Manager

  • Assessing the risk of the August security updates

    Today we released fourteen security bulletins. Eight have a maximum severity rating of Critical with the other six having a maximum severity rating of Important. Furthermore, six of the fourteen bulletins either do not affect the latest version of our products or affect them with reduced severity. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Index Likely first 30 days impact Platform mitigations and key notes
    MS10-055
    (Cinepak)
    Victim browses to a malicious webpage or opens a malicious AVI movie with Media Player. Critical 1 Likely to see an exploit released able to exploit the vulnerability in the Cinepak codec. Vulnerable DLL does not exist on Windows Server 2003 or Windows Server 2008.
    MS10-052
    (MPEG-3)
    Victim browses to a malicious webpage or opens a malicious ASX file with Media Player. Critical 1 Likely to see an exploit released able to exploit the vulnerability in MPEG-3 codec. Only Windows XP and Windows Server 2003 are vulnerable.
    MS10-056
    (Word, RTF)
    Victim opens malicious RTF file using Microsoft Word or views RTF email using Outlook 2007. Critical 1 RTF exploit likely to be developed. Office 2010 not affected.
    Versions of Outlook prior to 2007 did not use Word as RTF parser so are not susceptible to Outlook attack vector.
    MS10-060
    (Silverlight, .NET framework)
    Victim browses to a malicious webpage. Critical 1 Likely to see an exploit released able to exploit the vulnerability in Silverlight.
    MS10-054
    (SMB)
    Windows XP system compromised via over-the-network SMB packet. Critical 2 Exploiting this vulnerability for code execution will be difficult. For more information on risk by platform, please see this SRD blog post.
    MS10-053
    (Internet Explorer)
    Victim browses to a malicious website. Critical 1
    (IE6 only)
    Consistent, reliable exploit affecting IE7 or IE8 will be difficult to develop. Vulnerabilities significantly more difficult to exploit on IE7 and IE8 due to platform mitigations.
    MS10-051
    (MSXML ActiveX)
    Victim browses to a malicious website. Critical 2 Difficult to build reliable exploit.
    MS10-049
    (schannel)
    Victim browses to a malicious https website. Critical 2 Exploiting CVE-2010-2566 for code execution will be difficult. Successful attacks would result in code execution as SYSTEM, making this an attractive target, despite its difficulty. Windows Vista and newer platforms are Important Severity. For more information please see this SRD blog post and this SRD blog post.
    MS10-050
    (Windows Movie Maker)
    Victim opens malicious MSWMM file sent via email or downloaded via website. Important 1 MSWMM exploit likely to be developed. Does not affect Windows Live Movie Maker shipped by default with Windows 7.
    MS10-057
    (Excel 2002, Excel 2003)
    Victims opens malicious XLS file sent via email or downloaded via website. Important 1 XLS exploit likely to be developed. Does not affect Office 2007 or Office 2010.
    MS10-048
    (Win32k)
    Attacker logged-in to a machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see an exploit developed for CVE-2010-1897 and potentially others.
    MS10-058
    (TCP/IP)
    Remote attacker causes victim machine to bugcheck. Attacker logged-in to machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see an exploit developed for one or both vulnerabilities. 64-bit Windows not affected by vulnerability allowing local elevation of privilege.
    MS10-059
    (Tracing service)
    Attacker logged-in to a machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see proof-of-concept code released
    MS10-047
    (Kernel)
    Attacker logged-in to a machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see proof-of-concept code released. The security impact on Windows Server 2008 R2 and Windows 7 is limited to denial of service.

    Thanks to all of MSRC Engineering for their work on these cases.

    - Jonathan Ness, MSRC Engineering

  • MS10-054: Exploitability Details for the SMB Server Update

    This month Microsoft released an update for Windows to address three vulnerabilities in the SMB Server component. Two of the vulnerabilities are remote denial-of-service (DoS) attacks, while one (CVE-2010-2550) has the potential for remote code execution (RCE). This blog post provides more details on the exploitability of CVE-2010-2550, and outlines why the risk of reliable RCE is low.

    As mentioned in the bulletin, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows 2008 R2 systems are not vulnerable to unauthenticated attackers by default. (Only if password-based sharing was disabled would one of these systems be vulnerable.) In the most common scenarios, and on these versions of Windows by default, the attacker would therefore need to be authenticated.

    Vulnerability details

    In order to exploit CVE-2010-2550, the attacker must have read permission on a SMB share on the target system. This implies that the attacker is authenticated, or that the target allows anonymous access to network shares (this is a default configuration only on Windows XP with later platforms requiring authentication by default)

    By sending a specially crafted SMB request to the target, an attacker with read access could cause a kernel pool block to be overrun. This is due to an attacker-provided length being used as the size value in an allocation call. If an attacker specifies a small size value, the system will later write data to this buffer, which will corrupt the adjacent pool block(s). The data used in the overwrite comes from the disk or file system on the target machine.

    Exploitability details

    Assuming the attacker is able to trigger the vulnerability, there are some factors that make reliable exploitation difficult:

    • Windows 7 and Windows 2008 R2 systems have mitigations in the kernel to prevent pool overrun exploitation which will make the remote attack even more difficult (as discussed here http://blogs.technet.com/b/srd/archive/2009/05/26/safe-unlinking-in-the-kernel-pool.aspx)
    • The data that will be written to the kernel pool block is not attacker-controlled and instead comes from the disk or file system on the target machine. Finding data that contains useful values in the right location for an attacker’s purposes will be difficult in a remote attack scenario. A local attacker has more control and might be able to allocate memory on the system in a way that allows corrupted pointers in the pool to be leveraged for local elevation of privilege (EOP).
    • Failed exploitation attempts will result in a system crash (bugcheck), so the attacker will only get one attempt (per boot) to exploit the vulnerability.

    For these reasons we think it will be difficult to build reliable RCE exploits for this vulnerability, and remote DoS attacks are much more likely. A local EOP exploit is possible. The risk of a worm spreading using this vulnerability is very low.

    Thanks to the following people for their hard work on this issue:

    • Bruce Dang, MSRC Engineering
    • Dustin Childs, MSRC
    • Kowshik Jaganathan, Hassan Sultan, Vivek Jain , Felix Coifman, Geoffrey Antos , Purujit Saha, Faraz Qadri, Shiraj Kashani and Anindya Das from the Windows Sustained Engineering
    • Shivani Sharma, Ather Haleem, Gary Shang, David Kruse and Greg Kramer from the Windows Core SMB
    • Julien Vanegue, MSEC Pentest

    Thanks to Fermin J. Serna and Andrew Roths for contributing to this blog post.

    - Mark Wodrich, MSRC Engineering

  • MS10-049: An inside look at CVE-2009-3555, the TLS renegotiation vulnerability

    This issue was identified by security researchers Marsh Ray and Steve Dispensa. The vulnerability exists because certain Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protected protocols assume that data received after a TLS renegotiation is sent by the same client as before the renegotiation. Renegotiation is TLS functionality that allows either peer to change the parameters of the secure session. In this post, we’ll explain how our fix works, and why the risk to most Microsoft customers is limited.

     

    TLS and SSL did not effectively guarantee this authenticity, and as a result, the underlying protocol would need to ensure that the renegotiated session is still with the same peer, something the protocol is often ill prepared for. An attacker with the ability to intercept traffic (for instance through an ARP spoofing attack, or DNS cache poisoning) could execute a man-in-the-middle attack, intercept a TLS renegotiation attempt, and partially pose as the authenticated client.

     

    By cleverly manipulating the protocol, the researchers identified that as man-in-the-middle, they could keep the client-end of the connection stalled, start up their own renegotiation with the server, and submit data. Once the server received it, they would restart the renegotiation, and pass the server’s renegotiation attempt back to the client as if nothing happened. While an attacker cannot use this to change or read encrypted information, it can be leveraged to prepend data to a secure connection.

     

    Some protocols are more affected than others. HTTPS for instance, is affected. An attacker can send an HTTPS request from the client to the server, and by splicing the request can have the actual client send through the authentication cookie. The server will read the request issued by the attacker, and attribute it to the authenticated client.

     

    The risk to most Microsoft customers, overall, is limited. While the TLS/SSL implementations for all vendors are affected, overall risk to our customers is limited. In order to exploit this vulnerability, the attacker needs to abuse TLS renegotiation already taking place between both peers.  Internet Information Services (IIS) 6 and 7, do not allow clients to initiate TLS renegotiation, removing the attacker’s ability to induce a vulnerable scenario. These servers will only start up renegotiation themselves when they are configured to  ‘accept’ certificate based mutual authentication. This is a non-default scenario. In addition, our team found a number of other reasons why this issue would be difficult to exploit. We published more detail on our overall risk assessment in this February blog entry.

     

    It is important to note that this is still potentially a significant issue for certain deployments, and the update should be installed. In particular, the vulnerability may affect other, non-HTTP protocols that are less well understood. When the vulnerability was identified, Microsoft worked through the Industry Consortium for Advancement of Security on the Internet (ICASI) to ensure that we had a TLS-layer fix which is compatible with third-party TLS implementations.

     

    The result of that collaboration, and hard work by many other security developers in the IETF TLS working group, led to the publication of RFC 5746, the TLS Renegotiation Indication Extension. This new standard, co-authored by Nasko Oskov in our Windows security engineering team, addresses the vulnerability by defining a TLS extension that cryptographically binds renegotiations to their initial TLS connection. With this fix installed, the TLS endpoint itself can validate whether the data sent still belongs to the same initial connection. There is no longer any requirement for the encapsulated protocol to do so.

     

    In order for a connection to be fully protected, both client and server need to have a TLS implementation that is RFC 5746 compliant. As of today, we’re happy to announce that Microsoft customers have an update available that will deploy this new functionality. We also know many other vendors have either released or are in the process of releasing support for this extension.

     

    We understand that administrators may have a need to require clients to have the update in order to connect to high-security applications. A registry key is available, documented in KB 980436, which allows the administrator to place a system in “Compatible” or “Strict” mode. In compatible mode, the default setting, the client will enable the use of this TLS extension, but not enforce it. A client connecting without the security update will still be able to successfully connect with peers that do not. In strict mode, both peers will require the standard in order to successfully connect.

     

    The following diagram displays this in more detail:

     

     

    Acknowledgements

     

    Thanks to the following for their work on this issue and feedback on the blog:

     

    Nasko Oskov from Windows Security Engineering
    Gavin Thomas and Robert Hensing from
    MSRC Engineering
    Manoj Thakur and Chunlin Shi from Windows Sustained Engineering

     

    Cheers,
    -Maarten Van Horenbeeck, MSRC Program Manager

     

  • MS10-048 an explanation of the Defense in Depth fixes

    Today we released several fixes on MS10-048 affecting the win32k.sys kernel component. The most severe vulnerability allows a local user to perform an authenticated elevation of privileges, with no possible remote vector.

     

    This update also includes several “Defense in Depth” measures that correct potential integer overflows in unrealistic scenarios. In this blog post we are going to walk you through these vulnerabilities to help explain the technical reasoning behind the DiD rating.

     

    In order to understand these issues we first need to understand the source code involved. The win32k.sys component, among other things, is responsible for handling and forwarding windows messages. Before handling or forwarding them, win32k.sys will validate the messages and their parameters: probing, fetching from user mode, validating sizes, pointers, etc…

     

    While handling a certain type of request, and before forwarding it to the top windows on the desktop, several potential integer overflows can happen that would bypass the before mentioned checks. All these are similar to the one that we will focus on:

     

                 case DBT_DEVTYP_PORT:

                    pPortW = (PDEV_BROADCAST_PORT_W)lParam;

                    if ((1+wcslen(pPortW->dbcp_name))*sizeof(WCHAR) + FIELD_OFFSET(DEV_BROADCAST_PORT_W, dbcp_name) > cbSize) {

                        MSGERRORCLEANUP(0);

                    }

                    break;

     

     

    An attacker could control the value of pPortW->dbcp_name, which is already probed and captured locally in kernel space.

     

    On 32 bit systems an integer overflow can happen if wcslen() returns more than 2^311.  This would require having a 2^321 byte string captured in kernel mode plus the same one in user mode, 2^33 in total. This is not possible on current 32bit systems since with this 32bit range you can only have 2^32 bytes of virtual memory per process shared by user mode and kernel mode

     

    However, that still leaves 64 bit systems.  In order to see if this could be exploitable on 64 bit system we will go to the assembly level.

     

                    0:000> u fffff97f`ff07474c

                    fffff97f`ff07474c 488d7b0c        lea     rdi,[rbx+0Ch]

                    fffff97f`ff074750 33c0                xor     eax,eax

                    fffff97f`ff074752 4883c9ff         or      rcx,0FFFFFFFFFFFFFFFFh

                    fffff97f`ff074756 66f2af             repne scas word ptr [rdi] <- inlined wcslen

                    fffff97f`ff074759 48f7d1            not     rcx <- rcx contains the length

                    fffff97f`ff07475c 488d4c090c   lea     rcx,[rcx+rcx+0Ch] <- this does not overflow unless you have a really big (length ~ 2^63 )

                    fffff97f`ff074761 493bcc          cmp     rcx,r12 <- compare against cbSize…

                    fffff97f`ff074764 7609            jbe     fffff97f`ff07476f

                    0:000>

     

    The comparison from the above source code is up-casted on 64 bit systems. Again, the attacker needs a really big string in user space (plus the local copy at kernel space).  That’s 2^65 bytes of data and is not possible on current 64bit systems either.

     

    So, why are we fixing it? If there is a future recompilation or source change and the comparison is down-casted to 32 bits this could potentially be exploitable on 64 bit systems. Adding that to the fact that we have fixes in the close area makes this a worthy effort.

     

    -Fermin J. Serna, MSRC Engineering

     

    1 These two values are rounded up.  Technically the value that must be bypassed is a few bytes less.  However, this does not change the overall argument as the size of the string is too large to be allocated on the system.

  • MS10-049: A remote Code Execution vulnerability in SChannel, CVE-2010-2566

    In MS10-049, we are also addressing a second vulnerability, CVE-2010-2566. This is a vulnerability in schannel.dll which can potentially lead to Remote Code Execution. The vulnerability is present only in Windows XP and Windows Server 2003, and does not affect Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2.

     

    This vulnerability is present in the code that validates client certificate requests sent by the server. An attacker could set up a malicious TLS or SSL-enabled server, and convince a user to connect to it using a Windows client application.

     

    A malicious server could then respond with a specifically crafted message in a way that induces heap corruption on the client, leading to a crash of the Local Security Authority Subsystem Service (LSASS). Theoretically, this is an exploitable condition, and the attacker could then arbitrary code as LocalSystem.

     

    A detailed investigation by our team, however, has indicated that the attacker has very little control over what is written to the heap. This vulnerability has an Exploitability Index rating of 2, which indicates we believe it’s unlikely that reliable exploit code will be published within 30 days.

     

    We do recommend customers to install this update, especially because it is difficult to build on-the-wire mitigation against this issue. In the TLS handshake protocol, the client certificate is usually requested inside the existing encrypted TLS channel. This makes it difficult for firewalls and intrusion prevention systems to successfully detect and block an attack.

     

    Acknowledgements

     

    Thanks to Mark Wodrich and Bruce Dang from the MSRC Engineering team for their contribution to this blog post.

     

    Cheers,
    -Maarten Van Horenbeeck, MSRC Program Manager