Isses with respect to malloc failures handling.
Srinivas Koripella
skoripella at juniper.net
Mon Dec 14 06:45:55 UTC 2015
Hello all,
Found a handful of issues w.r.t to malloc failures handling in openssl code. Please note that all of these happen when the malloc has failed and returned NULL.
========================================================================================
Issue 1)
We could have failed to allocate the ctx->cipher_data in EVP_CipherInit_ex
ctx->cipher_data = OPENSSL_malloc(ctx->cipher->ctx_size);
if (!ctx->cipher_data) {
EVPerr(EVP_F_EVP_CIPHERINIT_EX, ERR_R_MALLOC_FAILURE);
return 0;
}
We do subsequently return error from EVP_CipherInit_ex. However during shutdown because of this error we are not checking for the NULL cipher_data causing cores
with the below bt.
The bt is as below.
(gdb) bt
0 0x0000000001486ed0 in rc4_hmac_md5_ctrl (ctx=0x7692e020, type=<optimized out>, arg=13,
ptr=0x7fba15ffe9a0) at ../../../../../../src/crypto/openssl/crypto/evp/e_rc4_hmac_md5.c:274
1 0x00000000014ae3c4 in EVP_CIPHER_CTX_ctrl (ctx=0x7692e020, type=369093024, arg=2,
ptr=0x7fba15ffe9a0) at ../../../../../../src/crypto/openssl/crypto/evp/evp_enc.c:606
2 0x00000000013a4e85 in tls1_enc (s=0x7ddbba10, send=1)
at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:828
3 0x00000000013954e3 in do_ssl3_write (s=0x7ddbba10, type=21, buf=0x7e477148 "\001", len=2,
create_empty_fragment=0) at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:951
4 0x000000000139566d in ssl3_dispatch_alert (s=0x7692e020)
at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1704
5 0x0000000001394e73 in ssl3_send_alert (s=0x7ddbba10, level=1, desc=0)
at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1690
6 0x0000000001398378 in ssl3_shutdown (s=0x7692e020)
at ../../../../../../src/crypto/openssl/ssl/s3_lib.c:4205
7 0x0000000001391755 in SSL_shutdown (s=0x7ddbba10)
========================================================================================
Issue 2
In file pmeth_gn.c function EVP_PKEY_keygen, openssl code tries to allocate EVP_PKEY using EVP_PKEY_new and immediately follows with a dereference of the same in the below path without checking if the allocation was successful or not.
(gdb) bt
at ../../../../../../src/crypto/openssl/crypto/evp/p_lib.c:258
at ../../../../../../src/crypto/openssl/crypto/hmac/hm_pmeth.c:140
at ../../../../../../src/crypto/openssl/crypto/evp/pmeth_gn.c:150
key=0x7779ff14 "\[L \\351\\302\\202M\\"\\326 \\b\\361\\275\\267\\n\\300\\205I\\277\\023\\344\\346D\\341+K5\\331d\\327(\\177\\"\\237\\027\\065\\273TT\\346\\335\\246\\343\\242\\256", keylen=48) at ../../../../../../src/crypto/openssl/crypto/evp/pmeth_gn.c:209
seed5=<optimized out>, seed4_len=<optimized out>, seed4=<optimized out>, seed3_len=<optimized out>,
seed3=<optimized out>, seed2_len=<optimized out>, seed2=<optimized out>, seed1_len=<optimized out>,
seed1=<optimized out>, sec_len=<optimized out>, sec=<optimized out>, md=<optimized out>)
at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:177
======================================================================================
Issue 3:
In file s3_enc.c in function ssl3_digest_cached_records, EVP_DigestInit_ex is called to initialize the EVP digest. Internally to EVP_DigestInit_ex ctx->md_data is allocated and if it fails an error is returned. However in ssl3_digest_cached_records the return value is not checked, causing a null dereference with the below backtrace.
at ../../../../../../src/crypto/openssl/crypto/evp/m_sha1.c:127
at ../../../../../../src/crypto/openssl/crypto/evp/digest.c:251
at ../../../../../../src/crypto/openssl/ssl/s3_enc.c:660
=======================================================================================
Issue 4:
In file ssl_lib.c, in function ssl_replace_hash, an EVP_MD_CTX is created using EVP_MD_CTX_create. However, the return value of this allocation is not checked and a dereference is made just below in EVP_DigestInit_ex causing a core.
=======================================================================================
Issue 5:
In tl_enc.c, in function tls1_enc in the case of
/\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/
openssl tries to dereference cipher after getting the value of cipher from s->enc_write_ctx. However cipher can be null. This can happen because we returned NULL in Issue 4) above and s->enc_write_ctx->cipher might not have been set. Typically
s->enc_write_ctx->cipher would have been set in the below path but because of Issue 4 above we did not set s->enc_write_ctx->cipher.
key=0x7789d9e0 "Y\\376\\b\\362w\\332)\\246\\203z3\\366F\\255\\030 \\302\\202\\037\\313om\\342\\317\\304+\\016\\347\\314\\071\\334\\016\`\\301ji\\325\\342\\272r\\202\\025\\312 at s\\241\\271q\\346@/A\\310Os\\223iFm\\356\\257\\314\\241\\331\\355%\\370t\\325\\026R\\306x\\344\\001/\\030\\063\\224/\\250\\205\\067\*\\\\\\241\\277\\250\\\\ \\216h\\226\\251\\350\\351",
iv=0x7789da20 "\\355%\\370t\\325\\026R\\306x\\344\\001/\\030\\063\\224/\\250\\205\\067\*\\\\\\241\\277\\250\\\\ \\216h\\226\\251\\350\\351",
enc=1) at ../../../../../../src/crypto/openssl/crypto/evp/evp_enc.c:176
at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:576
========================================================================================
Issue 6:
Similar issue as above exists in s3_pkt.c function do_ssl3_write in the case
/\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/ where again s->enc_write_ctx->cipher can be NULL.
=======================================================================================
Issue 7:
In file t1_enc.c, in function tls1_mac, openssl after calling EVP_DigestSignFinal has an assert on the return value to be greater than 0. However, EVP_DigestSignFinal internally allocates memory and if this memory allocation fails, an error is returned. Hence this assert is overaggressive for low memory cases. So Pls see if instead of coring, the error can be handled gracefully.
========================================================================================
Issue 8:
In file t1_enc.c, in function tls1_setup_key_block, memory is allocated twice for the keyblock through p1 and p2. If p1 succeeds but p2 fails, p1 is freed but the freed pointer p1 is left dangling inside s->s3->tmp.key_block which is later attempted to be freed while freeing s->s3 resulting in a double free.
The fix would be to set the s->s3->tmp.key_block to NULL
========================================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20151214/cbcb0614/attachment-0001.html>
More information about the openssl-bugs-mod
mailing list