Age | Commit message (Collapse) | Author |
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 44f206aa9dfd4f226f17d9093732dbece5300aa6)
|
|
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)
|
|
Ensure that we send a large message during the test suite.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 84d5549e692e63a16fa1b11603e4098fc31746e9)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
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>
|
|
Test that the OCSP callbacks work as expected.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Add a function for testing whether a given OCSP_RESPID matches with a
certificate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
OCSP_RESPID was made opaque in 1.1.0, but no accessors were provided for
setting the name/key value for the OCSP_RESPID.
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)
|
|
There are cases when argc is more trustable than proper argv termination.
Since we trust argc in all other test programs, we might as well treat it
the same way in this program.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 780bbb96bf514f0b4013e9c5725614ba5153c497)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
This issue is very similar to CVE-2016-6307 described in the previous
commit. The underlying defect is different but the security analysis and
impacts are the same except that it impacts DTLS.
A DTLS message includes 3 bytes for its length in the header for the
message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect TLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-6308
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 48c054fec3506417b2598837b8062aae7114c200)
|
|
A TLS message includes 3 bytes for its length in the header for the message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect DTLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-6307
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit c1ef7c971d0bbf117c3c80f65b5875e2e7b024b1)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 047d97afd97520eae268f6d8a36fbf9a0239a994)
|
|
If OPENSSL_sk_insert() calls OPENSSL_realloc() and it fails, it was leaking
the originally allocated memory.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 41bff723c6784cc846054a4fd4add6dbec8c2c64)
|
|
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>
(cherry picked from commit af58be768ebb690f78530f796e92b8ae5c9a4401)
|
|
Suggested in GH#1589.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 7dc0ad4d6dca81a003be7fa1fbd58a55f4be8646)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit ba8fa4e53a35a0c46d1e0e81a4d270a026fac2b9)
|
|
Reported in GH#1589, but solution is different from suggested.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 799c1293fcf412db64dcc8a09a6b11cc755914dc)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 776e15f9393a9e3083bec60a8da376ce2fe1e97e)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 6fcace45bda108ad4d3f95261494dd479720d92c)
|
|
Makes the logic a little bit clearer.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1571)
(cherry picked from commit 4f8a5f4da94bb70e06cf709beb1ddfa57a218c3d)
|
|
We should check the last BN_CTX_get() call to ensure that it isn't NULL
before we try and use any of the allocated BIGNUMs.
Issue reported by Shi Lei.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 1ff7425d6130380bb00d3e64739633a4b21b11a3)
|
|
This is a program for VMS that corresponds to util/shlib_wrap.sh.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit f3ff481f318b10a223d6157bde9645e1797487c5)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 47852e6ae763a40ddc3538c76a02be06fd0595a5)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit f6be8315cbdb4173008b5917d2b0fc80bb0bf06b)
|
|
Check arg count and print an error message.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 13a461831ab85ec9f55806ebf2df5ffb7f3f357a)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit a19228b7f4fc6fcb49713455b3caedbc24fb0b01)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 6e836806add140fa9e56d1226d7514fdfa2c803a)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 8c88c88b5ad43bbdf1f6e7602b6ac56c9031b153)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit f4566dff06d2539dd01f54c817e2b952b64452e4)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit ccf11f7ee49a0825caa407ed481c21b4b5933023)
|
|
Call SSL_CTX_new() before doing any configuration.
(or call OPENSSL_ssl_init())
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 54d72ef0f019db383f8e98342b9b77c5da8541e5)
|
|
'ECDHParameters = Automatic' isn't accepted.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 3656ea1c2217f38d44f3f34253e7c16f1b40ba77)
|
|
Note: server-cmod doesn't seem to do things right... from loading
cmod.cnf, it tries to load libssl_conf.so.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 16c6deed2c42d4cf4a7676a32b718d6a867f482a)
|
|
CMS_NOOLDMIMETYPE and PKCS7_NOOLDMIMETYPE are unused in pkcs7/cms code.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1585)
(cherry picked from commit 28aef3d9558dc2e11ba56576b3a4d3faaef8a9d3)
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1585)
(cherry picked from commit 12d56b2992ebd61e1b30c99ca1898dde42345cf7)
|
|
We were casting num_alloc to size_t in lots of places, or just using it in
a context where size_t makes more sense - so convert it. This simplifies
the code a bit.
Also tweak the style in stack.c a bit following on from the previous
commit
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 9205ebeb8e448b2d6948b9e5d78ecf309c0ed33c)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 9731a9ce7d0f404d21ed418f9bc983b174e130cb)
|
|
no-rsa is no longer an option since 7ec8de1
Fix a typo about poly1305
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1582)
(cherry picked from commit e2562bbbe1e1c68ec5a3e02c1f151fd6149ee2ae)
|
|
Some compilers complain about unused variables, and some tests do
not run well without OCSP.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 057c676afb2a69b7d2bb9cf6e895e720a2a62b78)
|
|
In an earlier attempt to simplify the processing of disabled options,
'no-err' and 'no-async' stopped working properly. 'err' and 'async'
are directories under 'crypto/', but they are special insofar that
they can't be simply skipped, like all the algorithm directories can,
so they need special treatment among the disablable things.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 66fe388aa410820d80ab1d99730b64b1b56a89d4)
|
|
While we're at it, correct the fault in windows-makefile.tmpl
Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 41240e68d745972d56dd037caf439d9c5032813f)
|