| Age | Commit message (Collapse) | Author |
|---|
|
DTLSv1_listen() is stateless. We never increment the record read sequence
while listening, and we reflect the incoming record's sequence number in our
write sequence.
The logic for doing the write sequence reflection was *after* we had
finished processing the incoming ClientHello and before we write the
ServerHello. In the normal course of events this is fine. However if we
need to write an early alert during ClientHello processing (e.g. no shared
cipher), then we haven't done the write sequence reflection yet. This means
the alert gets written with the wrong sequence number (it will just be set
to whatever value we left it in the last time we wrote something). If the
sequence number is less than expected then the client will believe that the
incoming alert is a retransmit and will therefore drop it, causing the
client to hang waiting for a response from the server.
Fixes #2886
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2915)
|
|
This shouldn't have been applied to the 1.0.2 branch.
This reverts commit 5247c0388610bfdcc8f44b777d75ab681120753d.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2907)
|
|
... in functions dealing with the SSL object rather than the context.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2870)
(cherry picked from commit d61461a7525322d188f9c6e3f90cfc93916cc636)
|
|
that refers to space
deallocated by a call to the free function in tls_decrypt_ticket.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2897)
(cherry picked from commit 13ed1afa923f4ffb553e389de08f26e9ce84e8a2)
|
|
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2750)
(cherry picked from commit 6aad9393680ccde591905c8d71da92a241756394)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2595)
|
|
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>
(Merged from https://github.com/openssl/openssl/pull/2625)
|
|
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.
(cherry picked from commit bd5d27c1c6d3f83464ddf5124f18a2cac2cbb37f)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2583)
|
|
- enable ssl3_init_finished_mac to return an error
- don't continue the SSL state machine if that happens
in ssl3_connect:
- if ssl3_setup_buffer fails also set state to SSL_ST_ERR for consistency
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2130)
|
|
- add error handling in ssl3_generate_key_block and ssl3_change_cipher_state
Fixes #2114
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2137)
|
|
When session tickets are used, it's possible that SNI might swtich the
SSL_CTX on an SSL. Normally, this is not a problem, because the
initial_ctx/session_ctx are used for all session ticket/id processes.
However, when the SNI callback occurs, it's possible that the callback
may update the options in the SSL from the SSL_CTX, and this could
cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things
can happen:
1. The session ticket TLSEXT may not be written when the ticket expected
flag is set. The state machine transistions to writing the ticket, and
the client responds with an error as its not expecting a ticket.
2. When creating the session ticket, if the ticket key cb returns 0
the crypto/hmac contexts are not initialized, and the code crashes when
trying to encrypt the session ticket.
To fix 1, if the ticket TLSEXT is not written out, clear the expected
ticket flag.
To fix 2, consider a return of 0 from the ticket key cb a recoverable
error, and write a 0 length ticket and continue. The client-side code
can explicitly handle this case.
Fix these two cases, and add unit test code to validate ticket behavior.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1065)
|
|
Fixed a memory leak in ASN1_digest and ASN1_item_digest.
asn1_template_noexp_d2i call ASN1_item_ex_free(&skfield,...) on error.
Reworked error handling in asn1_item_ex_combine_new:
- call ASN1_item_ex_free and return the correct error code if ASN1_template_new failed.
- dont call ASN1_item_ex_free if ASN1_OP_NEW_PRE failed.
Reworked error handing in x509_name_ex_d2i and x509_name_encode.
Fixed error handling in int_ctx_new and EVP_PKEY_CTX_dup.
Fixed a memory leak in def_get_class if lh_EX_CLASS_ITEM_insert fails due to OOM:
- to figure out if the insertion succeeded, use lh_EX_CLASS_ITEM_retrieve again.
- on error, p will be NULL, and gen needs to be cleaned up again.
int_free_ex_data needs to have a fallback solution if unable to allocate "storage":
- if free_func is non-zero this must be called to clean up all memory.
Fixed error handling in pkey_hmac_copy.
Fixed error handling in ssleay_rand_add and ssleay_rand_bytes.
Fixed error handling in X509_STORE_new.
Fixed a memory leak in ssl3_get_key_exchange.
Check for null pointer in ssl3_write_bytes.
Check for null pointer in ssl3_get_cert_verify.
Fixed a memory leak in ssl_cert_dup.
Fixes #2087 #2094 #2103 #2104 #2105 #2106 #2107 #2108 #2110 #2111 #2112 #2115
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2127)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2298)
|
|
When the client reads DH parameters from the TLS stream, we only
checked that they all are non-zero. This change updates the check
as follows:
check that p is odd
check that 1 < g < p - 1
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
- 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)
|
|
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/1984)
|
|
Dont free rbuf_freelist here, SSL_CTX_free will do that.
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
GH: #2129
|
|
Some versions of the Microsoft TLS stack have problems when the DHE public key
is encoded with fewer bytes than the DHE prime. (Backported from master)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1350)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2082)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2082)
|
|
- Always process ALPN (previously there was an early return in the
certificate status handling)
1.0.2 did not have the double-alert issue from master, but it seems
cleanest to pull in the structural change to alert handling anyway
and jump to f_err instead of err to send the alert in the caller.
(cherry picked from commit 70c22888c1648fe8652e77107f3c74bf2212de36)
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Commit fa4c37457 got reverted, so this one also needs to be reverted as
a result.
This reverts commit ad69a30323cbc6723c2387d6ce546a51b10c42d0.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Backport of beacb0f0c1ae7b0542fe053b95307f515b578eb7, revert of
fa4c374572e94f467900f5820cd1d00af2470a17
Fixes: #1903
Reviewed-by: Matt Caswell <matt@openssl.org>
GH: #1967
|
|
Avoid a memory alignment issue.
Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>
CLA: trivial
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1650)
|
|
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>
|
|
The heartbeat_test reaches into the internals of libssl and calls some
internal functions. It then checks the return value to check its what it
expected. However commit fa4c37457 changed the return value of these
internal functions, and now the test is failing.
The solution is to update the test to look for the new return value.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
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>
|
|
The SWEET32 fix moved 3DES from HIGH to MEDIUM, but omitted SSL2.
CLA: trivial
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1683)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Add a missing ifdef. Same change is already present in master.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1100)
|
|
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: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@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>
|
|
Certain warning alerts are ignored if they are received. This can mean that
no progress will be made if one peer continually sends those warning alerts.
Implement a count so that we abort the connection if we receive too many.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Grow TLS/DTLS 16 bytes more than strictly necessary as a precaution against
OOB reads. In most cases this will have no effect because the message buffer
will be large enough already.
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
The overflow check will never be triggered because the
the n2l3 result is always less than 2^24.
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
In ssl3_get_client_certificate, ssl3_get_server_certificate and
ssl3_get_certificate_request check we have enough room
before reading a length.
Thanks to Shi Lei (Gear Team, Qihoo 360 Inc.) for reporting these bugs.
CVE-2016-6306
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
This reverts commit 15d81749322c3498027105f8ee44e8c25479d475.
There were some unexpected side effects to this commit, e.g. in SSLv3 a
warning alert gets sent "no_certificate" if a client does not send a
Certificate during Client Auth. With the above commit this causes the
connection to abort, which is incorrect. There may be some other edge cases
like this so we need to have a rethink on this.
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Backport leak fix from master branch.
Thanks to Shi Lei (Gear Team, Qihoo 360 Inc.) for reporting this bug.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Thanks to Shi Lei (Gear Team, Qihoo 360 Inc.) for reporting this bug.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
A peer continually sending unrecognised warning alerts could mean that we
make no progress on a connection. We should abort rather than continuing if
we receive an unrecognised warning alert.
Thanks to Shi Lei for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
The function tls_construct_cert_status() is called by both TLS and DTLS
code. However it only ever constructed a TLS message header for the message
which obviously failed in DTLS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
(Modified for 1.0.2 by adding selected PACKET_xx() functions and PRF, and
subsequent cleanup from commit eb633d03fe2db3666840dee8d0a2dbe491672dfc)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 40425899200a3dea9ec3684d3eb80bcf50c99baf)
|
|
Baroque, almost uncommented code triggers behaviour which is undefined
by the C standard. You might quite reasonably not care that the code was
broken on ones-complement machines, but if we support a ubsan build then
we need to at least pretend to care.
It looks like the special-case code for 64-bit big-endian is going to
behave differently (and wrongly) on wrap-around, because it treats the
values as signed. That seems wrong, and allows replay and other attacks.
Surely you need to renegotiate and start a new epoch rather than
wrapping around to sequence number zero again?
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 2e94723c1b5d8ab974645e83de90b248265af3cd)
|
