| Age | Commit message (Collapse) | Author |
|---|
|
clang says: "s_cb.c:958:9: error: implicitly declaring library function
'memcpy'"
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 8f744cceff5bce8cb00a6ddd739c1bbb85c142ea)
Conflicts:
apps/s_cb.c
|
|
If sk_SSL_CIPHER_new_null() returns NULL then ssl_bytes_to_cipher_list()
should also return NULL.
Based on an original patch by mrpre <mrpre@163.com>.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 14def5f5375594830597cc153e11c6017f6adddf)
|
|
Reviewed-by: Rich Salz <rsalz@akamai.com>
|
|
Ensure all fatal errors transition into the new error state for DTLS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit cefc93910c4c0f7fa9f8c1f8f7aad084a7fa87d2)
Conflicts:
ssl/d1_srvr.c
|
|
Ensure all fatal errors transition into the new error state on the client
side.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit cc273a93617a5c1e69cb5db6f655e463f8e31806)
Conflicts:
ssl/s3_clnt.c
|
|
Ensure all fatal errors transition into the new error state on the server
side.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit cf9b0b6fb253fd40225d7c648a08646686e62d2d)
Conflicts:
ssl/s3_srvr.c
|
|
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 a89db885e0d8aac3a9df1bbccb0c1ddfd8b2e10a)
Conflicts:
ssl/s3_srvr.c
ssl/ssl_stat.c
|
|
Remove dependency on ssl_locl.h from v3_scts.c, and incidentally fix a build problem with
kerberos (the dependency meant v3_scts.c was trying to include krb5.h, but without having been
passed the relevanant -I flags to the compiler)
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit d13bd6130bd856e9f512c43499e5fc70943bf133)
Conflicts:
crypto/x509v3/v3_scts.c
|
|
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 8920a7cd04f43b1a090d0b0a8c9e16b94c6898d4)
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Was memset with wrong sizeof.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 23b0fa5ab6b6b9f0a9350e24ac5ddb8275802617)
|
|
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit bed2edf1cb73f1fe2c11029acc694086bc14443e)
|
|
Use sizeof *foo parameter, to avoid these errors.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 53ba0a9e91ad203de2943edaf1090ab17ec435fa)
|
|
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 539ed89f686866b82a9ec9a4c3b112878d29cd73)
|
|
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 34166d41892643a36ad2d1f53cc0025e2edc2a39)
|
|
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 3deeeeb61b0c5b9b5f0993a67b7967d2f85186da)
|
|
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 cb0f400b0cea2d2943f99b1e89c04ff6ed748cd5)
|
|
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 c427570e5098e120cbcb66e799f85c317aac7b91)
Conflicts:
ssl/ssl_locl.h
|
|
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 29b0a15a480626544dd0c803d5de671552544de6)
|
|
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 9d9e37744cd5119f9921315864d1cd28717173cd)
|
|
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 b86d7dca69f5c80abd60896c8ed3039fc56210cc)
|
|
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 c8269881093324b881b81472be037055571f73f3)
Conflicts:
ssl/record/ssl3_record.c
|
|
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 873fb39f20b6763daba226b74e83fb194924c7bf)
|
|
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>
|
|
This reverts commit 47daa155a31b0a54ce09ad2ed4d55fad74096dab.
The above commit was backported to the 1.0.2 branch as part of backporting
the alternative chain verify algorithm changes. However it has been pointed
out (credit to Shigeki Ohtsu) that this is unnecessary in 1.0.2 as this
commit is a work around for loop checking that only exists in master.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 6038354cf8ca0792420c1ac0ce50d6d2f0aedebf)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit a4d5269e6d0dba0c276c968448a3576f7604666a)
|
|
Cosmetic, no real effect.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 4446044a793a9103a4bc70c0214005e6a4463767)
|
|
Thanks to Brian Smith for reporting these issues.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Thanks to Brian Smith for reporting these issues.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 53dd4ddf71ad79a64be934ca19445b1cf560adab)
|
|
Also add a few comments about constant-timeness.
Thanks to Brian Smith for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
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)
|
|
EAP-FAST session resumption relies on handshake message lookahead
to determine server intentions. Commits
980bc1ec6114f5511b20c2e6ca741e61a39b99d6
and
7b3ba508af5c86afe43e28174aa3c53a0a24f4d9
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 6e3d015363ed09c4eff5c02ad41153387ffdf5af)
|
|
newsig may be used (freed) uninitialized on a malloc error.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 68249414405500660578b337f1c8dd5dd4bb5bcc)
|
|
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
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 06affe3dac65592a341547f5a47e52cedb7b71f8)
|
|
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 8817e2e0c998757d3bd036d7f45fe8d0a49fbe2d)
|
|
Fix miscellaneous NULL pointer derefs in the sureware engine.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 7b611e5fe8eaac9512f72094c460f3ed6040076a)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 7be6bc68c6baef87d4d730c2505a05810a5a1684)
|
|
This addresses
- request for improvement for faster key setup in RT#3576;
- clearing registers and stack in RT#3554 (this is more of a gesture to
see if there will be some traction from compiler side);
- more commentary around input parameters handling and stack layout
(desired when RT#3553 was reviewed);
- minor size and single block performance optimization (was lying around);
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 23f6eec71dbd472044db7dc854599f1de14a1f48)
|
|
Disable loop checking when we retry verification with an alternative path.
This fixes the case where an intermediate CA is explicitly trusted and part
of the untrusted certificate list. By disabling loop checking for this case
the untrusted CA can be replaced by the explicitly trusted case and
verification will succeed.
Signed-off-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e5991ec528b1c339062440811e2641f5ea2b328b)
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
the X509_V_FLAG_NO_ALT_CHAINS flag.
Conflicts:
doc/apps/cms.pod
doc/apps/ocsp.pod
doc/apps/s_client.pod
doc/apps/s_server.pod
doc/apps/smime.pod
doc/apps/verify.pod
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
X509_V_FLAG_NO_ALT_CHAINS flag. Using this option means that when building
certificate chains, the first chain found will be the one used. Without this
flag, if the first chain found is not trusted then we will keep looking to
see if we can build an alternative chain instead.
Conflicts:
apps/cms.c
apps/ocsp.c
apps/s_client.c
apps/s_server.c
apps/smime.c
apps/verify.c
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
behaviour will force behaviour as per previous versions of OpenSSL
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
valid. However the issuer of the leaf, or some intermediate cert is in fact
in the trust store.
When building a trust chain if the first attempt fails, then try to see if
alternate chains could be constructed that are trusted.
RT3637
RT3621
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
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 a0eed48d37a4b7beea0c966caf09ad46f4a92a44)
|
|
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 3ae91cfb327c9ed689b9aaf7bca01a3f5a0657cb)
|
|
The disabled set of -Weverything is hard to maintain across versions.
Use -Wall -Wextra but also document other useful warnings that currently trigger.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <gitlab@openssl.org>
|
|
Reported by Hanno Böck <hanno@hboeck.de>
PR#3800
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c4137b5e828d8fab0b244defb79257619dad8fc7)
|
|
Reported by Hanno Böck <hanno@hboeck.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 111b60bea01d234b5873488c19ff2b9c5d4d58e9)
|
