Possible Issues with Null Dereferences in s3_enc.c

[Srinivas Koripella]

Hello all,
We found out two issues in s3_enc.c causing null dereferences. Kindly note that in both the cases malloc returned NULL causing these crashes.

Issue 1) In function ssl3_init_finished_mac, we try to allocate s->s3->handshake_buffer but there is no check on whether we succeeded or not. If we fail here, we later dereference null in the below codepath causing crashes. Note that although we panic by dereferencing s->s3->handshake_dgst the actual cause is that this is being caused by s->s3->handshake_buffer being null as at this point during handshake only s->s3->handshake_buffer is allocated. s->s3->handshake_dgst is allocated later and is expected to be NULL here. The fix is to propogate the alloc failure upwards so we return error in the initial handshake path.

backtrace:
#0  0x00000000013a86c9 in ssl3_finish_mac (s=0x825100a0, buf=0xf3fc8535 "\001", len=98) at ../../../../../../src/crypto/openssl/ssl/s3_enc.c:599
#1  0x000000000139ff56 in ssl23_client_hello (s=<optimized out>) at ../../../../../../src/crypto/openssl/ssl/s23_clnt.c:585
#2  ssl23_connect (s=0x825100a0) at ../../../../../../src/crypto/openssl/ssl/s23_clnt.c:218


Issue 2) In ssl3_digest_cached_records we are calling EVP_MD_CTX_create to allocate individual MD_CTX. However, there is no check to see if the allocation succeeds or not. If the allocation fails, we dereference null subsequently in the call to EVP_DigestInit_ex.



Srinivas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20151203/28d78387/attachment-0001.html>