aboutsummaryrefslogtreecommitdiff
path: root/ssl
AgeCommit message (Collapse)AuthorFilesLines
2016-09-26Fix a WPACKET bugMatt Caswell1-3/+7
If we request more bytes to be allocated than double what we have already written, then we grow the buffer by the wrong amount. Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-09-22Convert HelloVerifyRequest construction to WPACKETMatt Caswell3-76/+96
We actually construct a HelloVerifyRequest in two places with common code pulled into a single function. This one commit handles both places. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-22Add warning about a potential pitfall with WPACKET_allocate_bytes()Matt Caswell2-1/+5
If the underlying BUF_MEM gets realloc'd then the pointer returned could become invalid. Therefore we should always ensure that the allocated memory is filled in prior to any more WPACKET_* calls. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-22Add -Wswitch-enumRich Salz3-82/+73
Change code so when switching on an enumeration, have case's for all enumeration values. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-09-22Avoid KCI attack for GOSTDmitry Belyavsky1-18/+0
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>
2016-09-22Fix a hang with SSL_peek()Matt Caswell1-1/+5
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>
2016-09-22Fix a mem leak in NPN handlingMatt Caswell1-0/+5
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>
2016-09-22Fix OCSP Status Request extension unbounded memory growthMatt Caswell1-7/+16
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>
2016-09-22Fix error message typo, wrong function codeRichard Levitte1-1/+1
Reviewed-by: Matt Caswell <matt@openssl.org>
2016-09-21Excessive allocation of memory in dtls1_preprocess_fragment()Matt Caswell1-17/+18
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>
2016-09-21Excessive allocation of memory in tls_get_message_header()Matt Caswell2-10/+11
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>
2016-09-21Don't allow too many consecutive warning alertsMatt Caswell5-0/+37
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>
2016-09-21Revert "Constify code about X509_VERIFY_PARAM"Rich Salz1-1/+1
This reverts commit 81f9ce1e1965e0e33db6d2391285c4c1b6af0434. Reviewed-by: Matt Caswell <matt@openssl.org>
2016-09-21make update and fix some associated mis-matched error codesMatt Caswell3-4/+6
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-09-20Quiet compiler warning about uninitialised variableRichard Levitte1-1/+1
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Convert WPACKET_put_bytes to use convenience macrosMatt Caswell8-44/+58
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: Rich Salz <rsalz@openssl.org>
2016-09-20Convert CCS construction to WPACKETMatt Caswell2-8/+36
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Convert Finished construction to WPACKETMatt Caswell1-9/+23
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Style tweaks following review feedbackMatt Caswell3-3/+3
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Convert NextProto message construction to WPACKETMatt Caswell2-11/+32
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Convert Certificate message construction to WPACKETMatt Caswell3-37/+34
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-20Convert ClientVerify Construction to WPACKETMatt Caswell4-19/+64
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-18Constify code about X509_VERIFY_PARAMFdaSilvaYY1-1/+1
Reviewed-by: Viktor Dukhovni <viktor@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1594)
2016-09-16Use switch instead of multiple ifsAlessandro Ghedini1-6/+8
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)
2016-09-15Revert "Abort on unrecognised warning alerts"Matt Caswell1-8/+2
This reverts commit 77a6be4dfc2ecf406c2559a99bea51317ce0f533. 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>
2016-09-14Fix OCSP_RESPID processing bug introduced by WPACKET changesMatt Caswell1-1/+1
An OCSP_RESPID in a status request extension has 2 bytes for the length not 1. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-14Encourage use of the macros for the various "sub" functionsMatt Caswell2-28/+32
Don't call WPACKET_sub_memcpy(), WPACKET_sub_allocation_bytes() and WPACKET_start_sub_packet_len() directly. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-14Add a WPACKET_sub_allocate_bytes() functionMatt Caswell4-31/+62
Updated the construction code to use the new function. Also added some convenience macros for WPACKET_sub_memcpy(). Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-14Convert CKE construction to use the WPACKET APIMatt Caswell3-87/+89
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Abort on unrecognised warning alertsMatt Caswell1-2/+8
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>
2016-09-13Fix a few style nits in the wpacket codeMatt Caswell3-6/+7
Addressing more feedback comments. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Remove else after a return in packet codeMatt Caswell1-2/+2
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Pull out some common packet code into a functionMatt Caswell1-25/+21
Two locations had the same loop for writing out a value. Pull it out into a function. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Add some soft asserts where applicableMatt Caswell1-1/+25
This is an internal API. Some of the tests were for programmer erorr and "should not happen" situations, so a soft assert is reasonable. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Address WPACKET review commentsMatt Caswell7-101/+79
A few style tweaks here and there. The main change is that curr and packet_len are now offsets into the buffer to account for the fact that the pointers can change if the buffer grows. Also dropped support for the WPACKET_set_packet_len() function. I thought that was going to be needed but so far it hasn't been. It doesn't really work any more due to the offsets change. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Simplify the overflow checks in WPACKET_allocate_bytes()Matt Caswell1-4/+1
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Move the WPACKET documentation comments to packet_locl.hMatt Caswell2-69/+87
The PACKET documentation is already in packet_locl.h so it makes sense to have the WPACKET documentation there as well. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Ensure the WPACKET gets cleaned up in the event of an errorMatt Caswell1-0/+1
Otherwise a mem leak can occur. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Various bug fixes and tweaks to WPACKET implementationMatt Caswell2-18/+73
Also added the WPACKET_cleanup() function to cleanup a WPACKET if we hit an error. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Add WPACKET_sub_memcpy() functionMatt Caswell4-24/+27
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Move from explicit sub-packets to implicit onesMatt Caswell9-261/+234
No need to declare an explicit sub-packet. Just start one. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Rename PACKETW to WPACKETMatt Caswell9-226/+226
To avoid confusion with the read PACKET structure. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13Convert tls_construct_client_hello() to use PACKETWMatt Caswell12-389/+583
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-13First pass at writing a writeable packets APIMatt Caswell3-1/+412
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-08Ensure trace recognises X25519Matt Caswell1-0/+1
Using the -trace option to s_server or s_client was incorrectly printing UNKNOWN for the X25519 curve. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-07Add missing debug strings.Rich Salz1-0/+20
Found by turning -Wswitch-enum on. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-08-30Ensure the CertStatus message adds a DTLS message header where neededMatt Caswell1-13/+14
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>
2016-08-26Remove trailing zerosRich Salz1-87/+73
Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-08-24Put DES into "not default" category.Rich Salz1-11/+11
Add CVE to CHANGES Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-08-24To avoid SWEET32 attack, move 3DES to weakRich Salz1-0/+18
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
generated by cgit v1.1 at 2024-09-15 02:45:43 +0000