DTLS Vulnerabilities in CVE-2014

Microsoft recently released a patch for a critical vulnerability in Microsoft Secure Channel (aka Schannel).  This vulnerability is being referred to as MS14-066.  The patch addressing CVE-2014-6321 fixed many areas within schannel.dll, including at least two vulnerabilities related to the handling of the Datagram Transport Layer Security (DTLS) protocol.

DTLS is used by Microsoft Remote Desktop Protocol (RDP) to provide communications privacy for datagram protocols.  The DTLS protocol is used by Microsoft Windows Remote Desktop Gateway (RDG) to establish a secure channel between the RDG client and RDG server (described in detail in [MS_TSGU].pdf).

DTLS Handshake

The RDG client initiates the DTLS connection by sending a ClientHello to the RDG Server.  The RDG server then responds with a DTLS Hello Verify Request that contains a cookie; this is used as a denial of service countermeasure.  The RDG client responds once again with a Client Hello packet containing the received cookie, which will initiate the DTLS handshake (RFC6347 Section 4.2).

 Figure 1: Initiation of the DTLS handshake between RDG client and server

Figure 2: RDG client and server handshake phase (Source: [MS-TSGU] Section 1.3.3.1.1)

Before starting analysis, we needed to set up a test environment. For the RDG server we referred to the following walkthrough: http://terrytlslau.tls1.cc/2014/01/deploying-remote-desktop-gateway-in.html.

Now let’s explore these vulnerabilities.

Server-Side DTLS Out Of Bounds (OOB) Read

When a client sends the DTLS ClientHello packet to the server, the server computes a Message Authentication Code (MAC) on it and compares it to the cookie contained in the packet. But the server only checks the cookie length field, not whether the cookie buffer can be read. In fact, a 32 byte length is always read, which could lead to a buffer out-of-bounds condition.

It should be noted that a client could send a crafted packet to the server without needing to start an RDP session. Figure 3, below, shows a packet crafted to display a “Cookie Length” of 32 (32 is equivalent to 0x20 in hexadecimal), which does not match the actual amount of data in the cookie (shown containing only two 0x41 characters).

Figure 3: A crafted packet sending mismatched size and content

Related code is found in the DTLSCookieManager::ValidateCookie function:

As shown above, although the server checks the “CookieSize” field, the compared length is always *(_DWORD *)(mgr + 16)), whose value is 0x20; however, the real cookie buffer length could be less than 0x20.  A crafted packet could set the “CookieSize” field to 0x20 and have the actual cookie buffer contain less than 0x20 bytes of data.

Client-Side Heap Overflow

When a DTLS client receives a HelloVerifyRequest packet with a CookieSize larger than 32 bytes the client does not properly validate the CookieSize value against the amount of cookie data in the packet. This scenario can result in a heap overflow. It should be noted that if you want modify the “CookieSize“ value, you should modify the other length fields to keep the packet structure valid, as shown below in Figure 4.

Figure 4: An example of a properly modified DTLS packet cookie

We can see the first packet is a normal ClientHello sent by the client, and the second packet is a crafted packet sent by the server.  In order to examine exploitation of this vulnerability, we used WinDBG to attach to the lsass.exe process. Below, Figure 5 shows what the call stack looks like when the process crashes.

Figure 5: WinDBG view of call stack when lsass.exe process crashes due to exploitation

Vulnerable code is found in the CSsl3TlsClientContext::DigestServerHelloVerifyRequest function:

Palo Alto Networks is releasing signature 37094 and 37059 to defend against these vulnerabilities.