- 22 9月, 2016 16 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Dmitry Belyavsky 提交于
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: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Matt Caswell 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Test that the OCSP callbacks work as expected. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Add a function for testing whether a given OCSP_RESPID matches with a certificate. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Matt Caswell 提交于
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: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
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: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
If OPENSSL_sk_insert() calls OPENSSL_realloc() and it fails, it was leaking the originally allocated memory. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Andy Polyakov 提交于
Suggested in GH#1589. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Andy Polyakov 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Andy Polyakov 提交于
Reported in GH#1589, but solution is different from suggested. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 21 9月, 2016 19 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Rich Salz 提交于
This reverts commit 81f9ce1e. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Richard Levitte 提交于
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: NMatt Caswell <matt@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
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: NRichard Levitte <levitte@openssl.org>
-
由 Richard Levitte 提交于
This is a program for VMS that corresponds to util/shlib_wrap.sh. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Rich Salz 提交于
Check arg count and print an error message. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Call SSL_CTX_new() before doing any configuration. (or call OPENSSL_ssl_init()) Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
'ECDHParameters = Automatic' isn't accepted. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Note: server-cmod doesn't seem to do things right... from loading cmod.cnf, it tries to load libssl_conf.so. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 20 9月, 2016 5 次提交
-
-
由 Matt Caswell 提交于
All the other functions that take an argument for the number of bytes use convenience macros for this purpose. We should do the same with WPACKET_put_bytes(). Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-