openssl, branch OpenSSL_1_1_0bTLS/SSL and crypto library.http://git.bktus.com/gpgfrontend/openssl/atom?h=OpenSSL_1_1_0b2016-09-26T09:46:03ZPrepare for 1.1.0b release2016-09-26T09:46:03ZMatt Caswellmatt@openssl.org2016-09-26T09:46:03Zurn:sha1:16c34d4f74e16443cfdc99f2a49ebb1ba3c37db3
Reviewed-by: Richard Levitte <levitte@openssl.org>
Updates CHANGES and NEWS for new release2016-09-26T09:25:13ZMatt Caswellmatt@openssl.org2016-09-26T08:43:45Zurn:sha1:87cd6f9253580866b13729d33fdd45205485b675
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add to fuzz corpora for CVE-2016-63092016-09-26T08:05:42ZRobert Swieckiswiecki@google.com2016-09-25T15:35:56Zurn:sha1:f8644220a05f75d51bbde627077cdf336e4d4592
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 44f206aa9dfd4f226f17d9093732dbece5300aa6)
Fix Use After Free for large message sizes2016-09-26T08:05:30ZMatt Caswellmatt@openssl.org2016-09-23T15:58:11Zurn:sha1:acacbfa7565c78d2273c0b2a2e5e803f44afefeb
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)
Add a test for large messages2016-09-26T08:05:17ZMatt Caswellmatt@openssl.org2016-09-23T14:37:13Zurn:sha1:df7681e46825d4a86df5dd73317d88923166a506
Ensure that we send a large message during the test suite.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 84d5549e692e63a16fa1b11603e4098fc31746e9)
Prepare for 1.1.0b-dev2016-09-22T10:15:54ZMatt Caswellmatt@openssl.org2016-09-22T10:15:54Zurn:sha1:5fe5914d3068128cdc6b08fe72746bb516a30b8a
Reviewed-by: Richard Levitte <levitte@openssl.org>
Prepare for 1.1.0a release2016-09-22T10:14:50ZMatt Caswellmatt@openssl.org2016-09-22T10:14:50Zurn:sha1:ac2c44c6289f9716de4c4beeb284a818eacde517
Reviewed-by: Richard Levitte <levitte@openssl.org>
Updates CHANGES and NEWS for new release2016-09-22T08:28:07ZMatt Caswellmatt@openssl.org2016-09-21T20:59:49Zurn:sha1:f3e189613fdbe7404bfbbca2caccf5cbd19e2ffc
Reviewed-by: Richard Levitte <levitte@openssl.org>
Avoid KCI attack for GOST2016-09-22T08:28:07ZDmitry Belyavskybeldmit@gmail.com2016-09-19T14:53:35Zurn:sha1:d3c9d6e99f075e6fbdab94db00b220cfa08b5c4b
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>
Fix a hang with SSL_peek()2016-09-22T08:28:07ZMatt Caswellmatt@openssl.org2016-09-10T20:24:40Zurn:sha1:63658103d4441924f8dbfc517b99bb54758a98b9
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>