- 05 May, 2015 1 commit
-
-
Matt Caswell authored
Reusing an SSL object when it has encountered a fatal error can have bad consequences. This is a bug in application code not libssl but libssl should be more forgiving and not crash. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit a89db885) Conflicts: ssl/s3_srvr.c ssl/ssl_stat.c
-
- 04 May, 2015 1 commit
-
-
Richard Levitte authored
RT2943 only complains about the incorrect check of -K argument size, we might as well do the same thing with the -iv argument. Before this, we only checked that the given argument wouldn't give a bitstring larger than EVP_MAX_KEY_LENGTH. we can be more precise and check against the size of the actual cipher used. (cherry picked from commit 8920a7cd ) Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
- 02 May, 2015 2 commits
-
-
Gilles Khouzam authored
Signed-off-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit bed2edf1)
-
Hanno Böck authored
Signed-off-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 539ed89f)
-
- 30 Apr, 2015 9 commits
-
-
Matt Caswell authored
The problem occurs in EVP_PKEY_sign() when using RSA with X931 padding. It is only triggered if the RSA key size is smaller than the digest length. So with SHA512 you can trigger the overflow with anything less than an RSA 512 bit key. I managed to trigger a 62 byte overflow when using a 16 bit RSA key. This wasn't sufficient to cause a crash, although your mileage may vary. In practice RSA keys of this length are never used and X931 padding is very rare. Even if someone did use an excessively short RSA key, the chances of them combining that with a longer digest and X931 padding is very small. For these reasons I do not believe there is a security implication to this. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 34166d41)
-
Matt Caswell authored
Add a sanity check to the print_bin function to ensure that the |off| argument is positive. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 3deeeeb6)
-
Matt Caswell authored
Sanity check the |len| parameter to ensure it is positive. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit cb0f400b)
-
Matt Caswell authored
The return value is checked for 0. This is currently safe but we should really check for <= 0 since -1 is frequently used for error conditions. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit c427570e) Conflicts: ssl/ssl_locl.h Conflicts: ssl/ssl_locl.h
-
Matt Caswell authored
For SSLv3 the code assumes that |header_length| > |md_block_size|. Whilst this is true for all SSLv3 ciphersuites, this fact is far from obvious by looking at the code. If this were not the case then an integer overflow would occur, leading to a subsequent buffer overflow. Therefore I have added an explicit sanity check to ensure header_length is always valid. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 29b0a15a)
-
Matt Caswell authored
The static function dynamically allocates an output buffer if the output grows larger than the static buffer that is normally used. The original logic implied that |currlen| could be greater than |maxlen| which is incorrect (and if so would cause a buffer overrun). Also the original logic would call OPENSSL_malloc to create a dynamic buffer equal to the size of the static buffer, and then immediately call OPENSSL_realloc to make it bigger, rather than just creating a buffer than was big enough in the first place. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 9d9e3774)
-
Matt Caswell authored
There was already a sanity check to ensure the passed buffer length is not zero. Extend this to ensure that it also not negative. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit b86d7dca)
-
Matt Caswell authored
The various implementations of EVP_CTRL_AEAD_TLS_AAD expect a buffer of at least 13 bytes long. Add sanity checks to ensure that the length is at least that. Also add a new constant (EVP_AEAD_TLS1_AAD_LEN) to evp.h to represent this length. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit c8269881) Conflicts: ssl/record/ssl3_record.c Conflicts: apps/speed.c crypto/evp/e_aes_cbc_hmac_sha256.c crypto/evp/evp.h
-
Matt Caswell authored
Add a sanity check to DES_enc_write to ensure the buffer length provided is not negative. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 873fb39f)
-
- 29 Apr, 2015 1 commit
-
-
Matt Caswell authored
Fortify flagged up a problem in n_do_ssl_write() in SSLv2. Analysing the code I do not believe there is a real problem here. However the logic flows are complicated enough that a sanity check of |len| is probably worthwhile. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit c5f8cd7b)
-
- 22 Apr, 2015 1 commit
-
-
Loganaden Velvindron authored
The function CRYPTO_strdup (aka OPENSSL_strdup) fails to check the return value from CRYPTO_malloc to see if it is NULL before attempting to use it. This patch adds a NULL check. RT3786 Signed-off-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 37b0cf936744d9edb99b5dd82cae78a7eac6ad60) Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 20d21389c8b6f5b754573ffb6a4dc4f3986f2ca4)
-
- 21 Apr, 2015 3 commits
-
-
Emilia Kasper authored
EAP-FAST session resumption relies on handshake message lookahead to determine server intentions. Commits 980bc1ec and 7b3ba508 removed the lookahead so broke session resumption. This change partially reverts the commits and brings the lookahead back in reduced capacity for TLS + EAP-FAST only. Since EAP-FAST does not support regular session tickets, the lookahead now only checks for a Finished message. Regular handshakes are unaffected by this change. Reviewed-by:
David Benjamin <davidben@chromium.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 6e3d0153)
-
Emilia Kasper authored
newsig may be used (freed) uninitialized on a malloc error. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 68249414)
-
Emilia Kasper authored
Reviewed-by:
Dr. Stephen Henson <steve@openssl.org>
-
- 20 Apr, 2015 3 commits
-
-
Richard Levitte authored
The logic with how 'ok' was calculated didn't quite convey what's "ok", so the logic is slightly redone to make it less confusing. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 06affe3d)
-
Matt Caswell authored
Filled in lots of return value checks that were missing the GOST engine, and added appropriate error handling. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 8817e2e0)
-
Matt Caswell authored
Fix miscellaneous NULL pointer derefs in the sureware engine. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 7b611e5f)
-
- 18 Apr, 2015 1 commit
-
-
Dr. Stephen Henson authored
Fix bug where i2c_ASN1_INTEGER mishandles zero if it is marked as negative. Thanks to Huzaifa Sidhpurwala <huzaifas@redhat.com> and Hanno Böck <hanno@hboeck.de> for reporting this issue. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit a0eed48d)
-
- 17 Apr, 2015 1 commit
-
-
Emilia Kasper authored
A 0-length ciphers list is never permitted. The old code only used to reject an empty ciphers list for connections with a session ID. It would later error out on a NULL structure, so this change just moves the alert closer to the problem source. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 3ae91cfb)
-
- 16 Apr, 2015 4 commits
-
-
Viktor Dukhovni authored
Reviewed-by:
Matt Caswell <gitlab@openssl.org>
-
Andy Polyakov authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Dr. Stephen Henson authored
Reported by Hanno Böck <hanno@hboeck.de> PR#3800 Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit c4137b5e)
-
Dr. Stephen Henson authored
Reported by Hanno Böck <hanno@hboeck.de> Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 111b60be)
-
- 14 Apr, 2015 2 commits
-
-
Matt Caswell authored
If OpenSSL is configured with no-tlsext then ssl_get_prev_session can read past the end of the ClientHello message if the session_id length in the ClientHello is invalid. This should not cause any security issues since the underlying buffer is 16k in size. It should never be possible to overrun by that many bytes. This is probably made redundant by the previous commit - but you can never be too careful. With thanks to Qinghao Tang for reporting this issue. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 5e0a80c1)
-
Matt Caswell authored
The ClientHello processing is insufficiently rigorous in its checks to make sure that we don't read past the end of the message. This does not have security implications due to the size of the underlying buffer - but still needs to be fixed. With thanks to Qinghao Tang for reporting this issue. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit c9642eb1ff79a30e2c7632ef8267cc34cc2b0d79)
-
- 11 Apr, 2015 2 commits
-
-
Kurt Roeckx authored
It would set gen->d.dirn to a freed pointer in case X509V3_NAME_from_section failed. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 8ec5c5dd)
-
Kurt Roeckx authored
Reviewed-by:
Viktor Dukhovni <openssl-users@dukhovni.org> (cherry picked from commit f49baeff)
-
- 10 Apr, 2015 1 commit
-
-
Dr. Stephen Henson authored
While *pval is usually a pointer in rare circumstances it can be a long value. One some platforms (e.g. WIN64) where sizeof(long) < sizeof(ASN1_VALUE *) this will write past the field. *pval is initialised correctly in the rest of ASN1_item_ex_new so setting it to NULL is unecessary anyway. Thanks to Julien Kauffmann for reporting this issue. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit f617b496) Conflicts: crypto/asn1/tasn_new.c
-
- 08 Apr, 2015 3 commits
-
-
Richard Levitte authored
Since source reformat, we ended up with some error reason string definitions that spanned two lines. That in itself is fine, but we sometimes edited them to provide better strings than what could be automatically determined from the reason macro, for example: {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER), "Peer haven't sent GOST certificate, required for selected ciphersuite"}, However, mkerr.pl didn't treat those two-line definitions right, and they ended up being retranslated to whatever the macro name would indicate, for example: {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER), "No gost certificate sent by peer"}, Clearly not what we wanted. This change fixes this problem. Reviewed-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 2cfdfe09)
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 37d92b1b)
-
Emilia Kasper authored
There is no indication that the timing differences are exploitable in OpenSSL, and indeed there is some indication (Usenix '14) that they are too small to be exploitable. Nevertheless, be careful and apply the same countermeasures as in s3_srvr.c Thanks to Nimrod Aviram, Sebastian Schinzel and Yuval Shavitt for reporting this issue. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit ae50d827)
-
- 07 Apr, 2015 1 commit
-
-
John Foley authored
Resolve a problem when using s_server with ECDHE cipher suites in OpenSSL_1_0_1-stable. Due to an uninitialized variable, SSL_CTX_set_tmp_ecdh() is not always invoked within s_server. This bug appears to have been introduced by 05990777 . Reviewed-by:
Tim Hudson <tjh@openssl.org>
-
- 31 Mar, 2015 1 commit
-
-
Douglas E Engert authored
RFC5915 requires the use of the I2OSP primitive as defined in RFC3447 for storing an EC Private Key. This converts the private key into an OCTETSTRING and retains any leading zeros. This commit ensures that those leading zeros are present if required. Reviewed-by:
Andy Polyakov <appro@openssl.org> (cherry picked from commit 30cd4ff2) Conflicts: crypto/ec/ec_asn1.c
-
- 25 Mar, 2015 3 commits
-
-
Emilia Kasper authored
While a true positive, it's almost harmless because EVP_DecryptInit_ex would have to fail and that doesn't happen under normal operation. Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
if CAfile or CApath were also supplied and successfully loaded first. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 70e5fd87)
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org>
-