Re: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers.
Thanks ViKtor. I tested your patch and it is holding up well on our environment. Srinivas -Original Message- From: The default queue via RT [mailto:r...@openssl.org] Sent: Tuesday, December 22, 2015 10:04 AM To: Srinivas Koripella Subject: [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Minor Issue with X509_STORE_CTX_init and it's callers.", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #4193]. Please include the string: [openssl.org #4193] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - Hello all, There is a minor issue with X509_STORE_CTX_init and its usage. Most of the callers of X509_STORE_CTX_init use a stack variable and pass its address as the ctx argument to this function. However, X509_STORE_CTX_init in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free on this stack variable. This in theory should be ok as the underlying free implementation should probably be a no-op as this address is from the stack. However, on systems that does strict checks on allocated memory heap this can be a problem. One potential fix could be to remove the OPENSSL_free and let the caller take responsibility for his memory. Thanks. Srinivas ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4193] Minor Issue with X509_STORE_CTX_init and it's callers.
Hello all, There is a minor issue with X509_STORE_CTX_init and its usage. Most of the callers of X509_STORE_CTX_init use a stack variable and pass its address as the ctx argument to this function. However, X509_STORE_CTX_init in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free on this stack variable. This in theory should be ok as the underlying free implementation should probably be a no-op as this address is from the stack. However, on systems that does strict checks on allocated memory heap this can be a problem. One potential fix could be to remove the OPENSSL_free and let the caller take responsibility for his memory. Thanks. Srinivas ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4180] Isses with respect to malloc failures handling.
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 0x01486ed0 in rc4_hmac_md5_ctrl (ctx=0x7692e020, type=, arg=13,
ptr=0x7fba15ffe9a0) at
../../../../../../src/crypto/openssl/crypto/evp/e_rc4_hmac_md5.c:274
1 0x014ae3c4 in EVP_CIPHER_CTX_ctrl (ctx=0x7692e020, type=369093024,
arg=2,
ptr=0x7fba15ffe9a0) at
../../../../../../src/crypto/openssl/crypto/evp/evp_enc.c:606
2 0x013a4e85 in tls1_enc (s=0x7ddbba10, send=1)
at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:828
3 0x013954e3 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 0x0139566d in ssl3_dispatch_alert (s=0x7692e020)
at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1704
5 0x01394e73 in ssl3_send_alert (s=0x7ddbba10, level=1, desc=0)
at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1690
6 0x01398378 in ssl3_shutdown (s=0x7692e020)
at ../../../../../../src/crypto/openssl/ssl/s3_lib.c:4205
7 0x01391755 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=, seed4_len=, seed4=,
seed3_len=,
seed3=, seed2_len=, seed2=,
seed1_len=,
seed1=, sec_len=, sec=,
md=)
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@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
[openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free
Description. We are dereferencing s->s3 in ssl3_free without checking if s->s3 is null or not. s->s3 can be null because of the below code path. SSL_new--> ssl3_new/tls1_new (via s->method->ssl_new) which allocates s3 and assigns s->s3 if successful. If not s->s3 will remain null as we memset entire contents of s to zero on allocation in SSL_new. However in SSL_new on return from the above s->method->ssl_new we go to err and call SSL_free which always calls s->method->ssl_free with us landing in ssl3_free with s->s3 as NULL. The fix should be to check for s->s3 and retrun if it is NULL immediately in ssl3_free before dereferencing it. Srinivas ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free
Yes. Malloc failed in our case. Srinivas -Original Message- From: Kurt Roeckx via RT [mailto:r...@openssl.org] Sent: Sunday, November 29, 2015 6:59 PM To: Srinivas Koripella Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free On Sun, Nov 29, 2015 at 11:09:34AM +, Srinivas Koripella via RT wrote: > Description. > > We are dereferencing s->s3 in ssl3_free without checking if s->s3 is null or > not. This has already been fixed in the current git versions. I'm wondering why you see this, you should only get this in case malloc() failed. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
