How MS14-066 (CVE-2014-6321) is More Serious Than First Thought

If you’ve been in a coma for the past week, MS14-066 (CVE-2014-6321) is a TLS heap overflow vulnerability in Microsoft’s schannel.dll, which can result in denial of service and even remote code execution on windows systems (the bug is exploitable during the TLS handshake stage, prior to any authentication). According to beyondtrust the problem exists in a function (schannel!DecodeSigAndReverse) which is used by the function responsible for verifying ECDSA (ECC) client certificates. The function passes the ECC signature to CryptDecodeObject and uses the returned length parameter to allocate some heap space, but then uses a separate value derived from the decoded object to copy to that memory (modifying the signature in a certain way will result in the copied memory exceeding the size of the buffer, causing a heap overflow). The problem with MS14-066 is that in order to exploit the vulnerability, you’d need a service which uses schannel and accepts client certificates (this rules out Remote Desktop). As beyond trust showed us, IIS can be configured to require or allow client certificates, thus becomes exploitable. Obviously SSL client authentication is only used in special cases and IIS will ignore client certificates by default, so the bug should have very little impact.

If you read the TLS handsake specification, a client certificate can only be sent if the server first sends a client certificate request (Sending a client certificate without a prior request will result in the server telling you to go home and sober up, then forcibly closing the connection). IIS will only send a certificate request if client certificates are enabled, remote desktop will never. As it happens there is a second “bug” in schannel which makes MS14-066 far more dangerous. Microsoft’s schannel TLS implementation doesn’t exactly follow the standards and modifying the OpenSSL binaries to just stuff the client certificate down the servers throat, will result in it being processed anyway (uh-oh).

To test my theory, the first thing I did was install windows 7 32-bit in a virtual machine and setup IIS7 (making sure it is set to ignore client certificates), then I started a remote kernel debugging session and set a breakpoint on schannel!DecodeSigAndReverse (called by function responsible for handling client certificate) in lsass.exe, which processes SSL/TLS on behalf of most windows services (it’s a system service so any exploitation will always result in NT AUTHORITYSYSTEM privileges).

I started a normal TLS session to IIS with OpenSSL’s s_client to check the breakpoint was not hit (it wasn’t), next I modified the OpenSSL SSLv3 source to send a client certificates even though the server doesn’t ask for one.

Jackpot! It was even the same story with remote desktop (RDP), a protocol that doesn’t even support client certificates, I was still able to trigger a breakpoint. I don’t really understand much about ECDSA / ECC so I’m not sure exactly what to modify in the signature to trigger the heap overflow (I believe some people just modified random bytes until an overflow was triggers), but this is definitely exploitable on services that don’t allow client certificates, meaning that any un-patched system running IIS or RDP is exploitable (not just windows servers as previously thought).

For a more in depth look at ms14-066 see here – http://www.malwaretech.com/2014/11/ms14-066-in-depth-analysis.html