| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2822)
(cherry picked from commit a3004c820370b6bee82c919721fb1cbe95f72f3f)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2704)
(cherry picked from commit 79020b27beff060d02830870fdfd821fe8cbd439)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2607)
(cherry picked from commit a0179d0afb621a0875ddcfd939719a9628ac4444)
|
|
Following on from CVE-2017-3733, this removes the OPENSSL_assert() check
that failed and replaces it with a soft assert, and an explicit check of
value with an error return if it fails.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Changing the ciphersuite during a renegotiation can result in a crash
leading to a DoS attack. ETM has not been implemented in 1.1.0 for DTLS
so this is TLS only.
The problem is caused by changing the flag indicating whether to use ETM
or not immediately on negotiation of ETM, rather than at CCS. Therefore,
during a renegotiation, if the ETM state is changing (usually due to a
change of ciphersuite), then an error/crash will occur.
Due to the fact that there are separate CCS messages for read and write
we actually now need two flags to determine whether to use ETM or not.
CVE-2017-3733
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2636)
(cherry picked from commit ed874fac6399d5064d6eb8fe2022b918aeaf75af)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2618)
(cherry picked from commit 57b0d651f052ed86528da916397acbcce035fb21)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2559)
(cherry picked from commit e0670973d5c0b837eb5a9f1670e47107f466fbc7)
|
|
While it's always safe to read |SSL_MAX_SSL_SESSION_ID_LENGTH| bytes
from an |SSL_SESSION|'s |session_id| array, the hash function would do
so with without considering if all those bytes had been written to.
This change checks |session_id_length| before possibly reading
uninitialised memory. Since the result of the hash function was already
attacker controlled, and since a lookup of a short session ID will
always fail, it doesn't appear that this is anything more than a clean
up.
In particular, |ssl_get_prev_session| uses a stack-allocated placeholder
|SSL_SESSION| as a lookup key, so the |session_id| array may be
uninitialised.
This was originally found with libFuzzer and MSan in
https://boringssl.googlesource.com/boringssl/+/e976e4349d693b4bbb97e1694f45be5a1b22c8c7,
then by Robert Swiecki with honggfuzz and MSan here. Thanks to both.
Reviewed-by: Geoff Thorpe <geoff@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2583)
(cherry picked from commit bd5d27c1c6d3f83464ddf5124f18a2cac2cbb37f)
|
|
Fixed a memory leak in ASN1_digest and ASN1_item_digest.
Reworked error handling in asn1_item_embed_new.
Fixed error handling in int_ctx_new and EVP_PKEY_CTX_dup.
Fixed a memory leak in CRYPTO_free_ex_data.
Reworked error handing in x509_name_ex_d2i, x509_name_encode and x509_name_canon.
Check for null pointer in tls_process_cert_verify.
Fixes #2103 #2104 #2105 #2109 #2111 #2115
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2163)
|
|
session_ctx and initial_ctx are aliases of each other, and with the
opaque data structures, there's no need to keep both around. Since
there were more references of session_ctx, replace all instances of
initial_ctx with session_ctx.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2340)
|
|
The pointer that was freed in the SSLv2 section of ssl_bytes_to_cipher_list
may have stepped up from its allocated position. Use a pointer that is
guaranteed to point at the start of the allocated block instead.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2312)
(cherry picked from commit 63414e64e66e376654e993ac966e3b2f9d849d3b)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2297)
|
|
When the client reads DH parameters from the TLS stream, we only
checked that they all are non-zero. This change updates the check to
use DH_check_params()
DH_check_params() is a new function for light weight checking of the p
and g parameters:
check that p is odd
check that 1 < g < p - 1
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
|
|
This is 1.1.0-specific 8f77fab82486c19ab48eee07718e190f76e6ea9a redux.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Remove duplicate defines from EVP source files.
Most of them were in evp.h, which is always included.
Add new ones evp_int.h
EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK is now always defined in evp.h, so
remove conditionals on it
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2201)
(cherry picked from commit 9d6fcd4295fef7ebc4232aab85718a99d36cc50a)
|
|
Well, not as much, at least.
Commit 07afdf3c3ac97af4f2b4eec22a97f7230f8227e0 changed things so
that for SSLv2 format ClientHellos we store the cipher list in the
TLS format, i.e., with two bytes per cipher, to be consistent with
historical behavior.
However, the space allocated for the array still performed the computation
with three bytes per cipher, a needless over-allocation (though a relatively
small one, all things considered).
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2281)
(cherry picked from commit f1429b85c5821e55224e5878da9d0fa420a41f71)
|
|
SSL_get0_raw_cipherlist() was a little too "raw" in the case of an SSLv2
compat ClientHello. In 1.0.2 and below, during version negotiation, if
we received an SSLv2 compat ClientHello but actually wanted to do SSLv3+
then we would construct a "fake" SSLv3+ ClientHello. This "fake" ClientHello
would have its ciphersuite list converted to the SSLv3+ format. It was
this "fake" raw list that got saved away to later be returned by a call to
SSL_get0_raw_cipherlist().
In 1.1.0+ version negotiation works differently and we process an SSLv2
compat ClientHello directly without the need for an intermediary "fake"
ClientHello. This meant that the raw ciphersuite list being saved was in
the SSLv2 format. Any caller of this function would not expect that and
potentially overread the returned buffer by one byte.
Fixes #2189
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2280)
(cherry picked from commit 07afdf3c3ac97af4f2b4eec22a97f7230f8227e0)
|
|
- s == NULL can mean c is a new session *or* lh_insert was
unable to create a hash entry.
- use lh_SSL_SESSION_retrieve to check for this error condition.
- If it happens simply remove the extra reference again.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2138)
(cherry picked from commit 38088ce9934a90d4aea486edbff864f3935342e6)
|
|
In a non client-auth renegotiation where the original handshake *was*
client auth, then the server will expect the client to send a Certificate
message anyway resulting in a connection failure.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1983)
|
|
In a non client-auth renegotiation where the original handshake *was*
client auth, then the client will send a Certificate message anyway
resulting in a connection failure.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1983)
|
|
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows:
B<Server mode:> only request a client certificate on the initial TLS/SSL
handshake. Do not ask for a client certificate again in case of a
renegotiation. This flag must be used together with SSL_VERIFY_PEER.
B<Client mode:> ignored
But the implementation actually did nothing. After the server sends its
ServerKeyExchange message, the code was checking s->session->peer to see if
it is NULL. If it was set then it did not ask for another client
certificate. However s->session->peer will only be set in the event of a
resumption, but a ServerKeyExchange message is only sent in the event of a
full handshake (i.e. no resumption).
The documentation suggests that the original intention was for this to
have an effect on renegotiation, and resumption doesn't come into it.
The fix is to properly check for renegotiation, not whether there is already
a client certificate in the session.
As far as I can tell this has been broken for a *long* time.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1983)
|
|
ssl3_change_cipher_state
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2164)
(cherry picked from commit a6fd7c1dbef2c3da3c87f1582ae48e4c29aa303c)
|
|
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1597)
(cherry picked from commit 3e37351834c203421b7f492dd83d5e5872e17778)
|
|
Otherwise the client will try to process it again. The second time around
it will try and move the record data into handshake fragment storage and
realise that there is no data left. At that point it marks it as read
anyway. However, it is a bug that we go around the loop a second time, so
we prevent that.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2200)
(cherry picked from commit 290a0419f0c13a30fb3a1d1a279125c8aeafd17e)
|
|
SSL_clear() was resetting numwpipes to 0, but not freeing any allocated
memory for existing write buffers.
Fixes #2026
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 4bf086005fe5ebcda5dc4d48ff701b41ab9b07f0)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
GH: #2050
(cherry picked from commit a19fc66a6b5f99ad00305e152bdb41460d728640)
|
|
Calling SSL_set_accept_state() after DTLSv1_listen() clears the state, so
SSL_accept() no longer works. In 1.0.2 calling DTLSv1_listen() would set
the accept state automatically. We should still do that.
Fixes #1989
Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 5bdcd362d24cbbcf18c5eb9df655fe9f7bcf5850)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Backport of beacb0f0c1ae7b0542fe053b95307f515b578eb7, revert of
122580ef71e4e5f355a1a104c9bfb36feee43759
Fixes: #1903
Reviewed-by: Matt Caswell <matt@openssl.org>
GH: #1966
|
|
ssl_test_old was reaching inside the SSL structure and changing the internal
BIO values. This is completely unneccessary, and was causing an abort in the
test when enabling TLSv1.3.
I also removed the need for ssl_test_old to include ssl_locl.h. This
required the addition of some missing accessors for SSL_COMP name and id
fields.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit e304d3e20f45243f9e643607edfe4db49c329596)
|
|
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1554)
(cherry picked from commit 1fa9ffd934429f140edcfbaf76d2f32cc21e449b)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1859)
(cherry picked from commit 7bb37cb5938a0cf76c12c8421950e72634d5f61c)
|
|
This partially reverts commit c636c1c47. It also tweaks the documentation
and comments in this area. On the client side the documented interface for
SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag
SSL_VERIFY_PEER causes verfication of the server certificate to take place.
Previously what was implemented was that if *any* flag was set then
verification would take place. The above commit improved the semantics to
be as per the documented interface.
However, we have had a report of at least one application where an
application was incorrectly using the interface and used *only*
SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to
the above commit this still caused verification of the server certificate
to take place. After this commit the application silently failed to verify
the server certificate.
Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate
if invalid flags were being used. However these are void functions!
The simplest short term solution is to revert to the previous behaviour
which at least means we "fail closed" rather than "fail open".
Thanks to Cory Benfield for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit c8e2f98c97ff3327784843946c2d62761572e5d5)
|
|
We read it later in grow_init_buf(). If CCS is the first thing received in
a flight, then it will use the init_msg from the last flight we received. If
the init_buf has been grown in the meantime then it will point to some
arbitrary other memory location. This is likely to result in grow_init_buf()
attempting to grow to some excessively large amount which is likely to
fail. In practice this should never happen because the only time we receive
a CCS as the first thing in a flight is in an abbreviated handshake. None
of the preceding messages from the server flight would be large enough to
trigger this.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c437757466e7bef632b26eaaf429a9e693330999)
|
|
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but
TLS 1.2 says you MUST send an unexpected message alert. We swap to the
TLS 1.2 behaviour for all protocol versions to prevent issues where no
progress is being made and the peer continually sends unrecognised record
types, using up resources processing them.
Issue reported by 郭志攀
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 436a2a0179416d2cc22b678b63e50c2638384d5f)
|
|
The function ssl3_read_n() takes a parameter |clearold| which, if set,
causes any old data in the read buffer to be forgotten, and any unread data
to be moved to the start of the buffer. This is supposed to happen when we
first read the record header.
However, the data move was only taking place if there was not already
sufficient data in the buffer to satisfy the request. If read_ahead is set
then the record header could be in the buffer already from when we read the
preceding record. So with read_ahead we can get into a situation where even
though |clearold| is set, the data does not get moved to the start of the
read buffer when we read the record header. This means there is insufficient
room in the read buffer to consume the rest of the record body, resulting in
an internal error.
This commit moves the |clearold| processing to earlier in ssl3_read_n()
to ensure that it always takes place.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit a7faa6da317887e14e8e28254a83555983ed6ca7)
|
|
Replace the various length checks in the extension code with a macro to
simplify the logic.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
The previous commit inspired a review of all the length checks for the
extension adding code. This adds more robust checks and adds checks where
some were missing previously. The real solution for this is to use WPACKET
which is currently in master - but that cannot be applied to release
branches.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
The status request extension did not correctly check its length, meaning
that writing the extension could go 2 bytes beyond the buffer size. In
practice this makes little difference because, due to logic in buffer.c the
buffer is actually over allocated by approximately 5k!
Issue reported by Guido Vranken.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
A zero return from BIO_read()/BIO_write() could mean that an IO operation
is retryable. A zero return from SSL_read()/SSL_write() means that the
connection has been closed down (either cleanly or not). Therefore we
should not propagate a zero return value from BIO_read()/BIO_write() back
up the stack to SSL_read()/SSL_write(). This could result in a retryable
failure being treated as fatal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 4880672a9b41a09a0984b55e219f02a2de7ab75e)
|
|
I use the word 'negotiation' advisedly. Because that's all we were doing.
We negotiated it, set the TLS1_FLAGS_ENCRYPT_THEN_MAC flag in our data
structure, and then utterly ignored it in both dtls_process_record()
and do_dtls1_write().
Turn it off for 1.1.0; we'll fix it for 1.1.1 and by the time that's
released, hopefully 1.1.0b will be ancient history.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 83ae4661315d3d0ad52ddaa8fa5c8f1055c6c6f6)
|
|
If we have a handshake fragment waiting then dtls1_read_bytes() was not
correctly setting the value of recvd_type, leading to an uninit read.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 2f2d6e3e3ccd1ae7bba9f1af62f97dfca986e083)
|
|
The buffer to receive messages is initialised to 16k. If a message is
received that is larger than that then the buffer is "realloc'd". This can
cause the location of the underlying buffer to change. Anything that is
referring to the old location will be referring to free'd data. In the
recent commit c1ef7c97 (master) and 4b390b6c (1.1.0) the point in the code
where the message buffer is grown was changed. However s->init_msg was not
updated to point at the new location.
CVE-2016-6309
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 0d698f6696e114a6e47f8b75ff88ec81f9e30175)
|
|
Russian GOST ciphersuites are vulnerable to the KCI attack because they use
long-term keys to establish the connection when ssl client authorization is
on. This change brings the GOST implementation into line with the latest
specs in order to avoid the attack. It should not break backwards
compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
If while calling SSL_peek() we read an empty record then we go into an
infinite loop, continually trying to read data from the empty record and
never making any progress. This could be exploited by a malicious peer in
a Denial Of Service attack.
CVE-2016-6305
GitHub Issue #1563
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
If a server sent multiple NPN extensions in a single ClientHello then a
mem leak can occur. This will only happen where the client has requested
NPN in the first place. It does not occur during renegotiation. Therefore
the maximum that could be leaked in a single connection with a malicious
server is 64k (the maximum size of the ServerHello extensions section). As
this is client side, only occurs if NPN has been requested and does not
occur during renegotiation this is unlikely to be exploitable.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
A malicious client can send an excessively large OCSP Status Request
extension. If that client continually requests renegotiation,
sending a large OCSP Status Request extension each time, then there will
be unbounded memory growth on the server. This will eventually lead to a
Denial Of Service attack through memory exhaustion. Servers with a
default configuration are vulnerable even if they do not support OCSP.
Builds using the "no-ocsp" build time option are not affected.
I have also checked other extensions to see if they suffer from a similar
problem but I could not find any other issues.
CVE-2016-6304
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit a449b47c7d8e20efc8cc524ed695a060b11ef889)
|
