Skip to main content
swh:1:snp:dc2a5002442a00b1c0eda7c65d04ea7455e166cd
sort by:
RevisionAuthorDateMessageCommit Date
888759a Matt Caswell22 September 2016, 10:30:27 UTCPrepare for 1.0.1u release Reviewed-by: Richard Levitte <levitte@openssl.org>22 September 2016, 10:30:27 UTC
16ec56f Matt Caswell21 September 2016, 22:20:45 UTCUpdates CHANGES and NEWS for new release Reviewed-by: Richard Levitte <levitte@openssl.org>21 September 2016, 23:29:03 UTC
ab650f0 Dmitry Belyavsky19 September 2016, 15:05:53 UTCAvoid KCI attack for GOST 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>21 September 2016, 23:25:58 UTC
2c0d295 Matt Caswell09 September 2016, 09:08:45 UTCFix OCSP Status Request extension unbounded memory growth 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>21 September 2016, 23:25:58 UTC
151adf2 Dr. Stephen Henson21 September 2016, 19:19:31 UTCupdate default dependency options Reviewed-by: Rich Salz <rsalz@openssl.org>21 September 2016, 19:19:31 UTC
bb1a486 Dr. Stephen Henson21 September 2016, 12:26:01 UTCMake message buffer slightly larger than message. 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> (cherry picked from commit 006a788c84e541c8920dd2ad85fb62b52185c519)21 September 2016, 19:01:32 UTC
8289755 Dr. Stephen Henson21 September 2016, 11:54:13 UTCUse SSL3_HM_HEADER_LENGTH instead of 4. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit bc9563f83d28342b5ec0073ec12d9e581e4f3317)21 September 2016, 19:01:10 UTC
aa388af Dr. Stephen Henson21 September 2016, 11:57:01 UTCRemove unnecessary check. 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> (cherry picked from commit 709ec8b3848e2ac201b86f49c5561debb8572ccd)21 September 2016, 19:00:46 UTC
52e623c Dr. Stephen Henson17 September 2016, 11:36:58 UTCFix small OOB reads. 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> (cherry picked from commit ff553f837172ecb2b5c8eca257ec3c5619a4b299)21 September 2016, 13:14:36 UTC
515a010 David Woodhouse08 July 2016, 19:46:07 UTCFix SSL_export_keying_material() for DTLS1_BAD_VER Commit d8e8590e ("Fix missing return value checks in SCTP") made the DTLS handshake fail, even for non-SCTP connections, if SSL_export_keying_material() fails. Which it does, for DTLS1_BAD_VER. Apply the trivial fix to make it succeed, since there's no real reason why it shouldn't even though we never need it. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit c8a18468caef4d62778381be0acdadc8a88d6e51)26 August 2016, 17:08:23 UTC
2b4029e Dr. Stephen Henson19 August 2016, 22:28:29 UTCAvoid overflow in MDC2_Update() Thanks to Shi Lei for reporting this issue. CVE-2016-6303 Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 55d83bf7c10c7b205fffa23fa7c3977491e56c07)24 August 2016, 13:24:53 UTC
e95f5e0 Rich Salz18 August 2016, 13:26:52 UTCSWEET32 (CVE-2016-2183): Move DES from HIGH to MEDIUM Reviewed-by: Viktor Dukhovni <viktor@openssl.org> Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit 0fff5065884d5ac61123a604bbcee30a53c808ff)24 August 2016, 12:58:00 UTC
1bbe48a Dr. Stephen Henson23 August 2016, 17:14:54 UTCSanity check ticket length. If a ticket callback changes the HMAC digest to SHA512 the existing sanity checks are not sufficient and an attacker could perform a DoS attack with a malformed ticket. Add additional checks based on HMAC size. Thanks to Shi Lei for reporting this bug. CVE-2016-6302 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit baaabfd8fdcec04a691695fad9a664bea43202b6)23 August 2016, 22:34:07 UTC
3612ff6 Kazuki Yamaguchi21 August 2016, 17:36:36 UTCFix overflow check in BN_bn2dec() Fix an off by one error in the overflow check added by 07bed46f332fc ("Check for errors in BN_bn2dec()"). Reviewed-by: Stephen Henson <steve@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 099e2968ed3c7d256cda048995626664082b1b30)22 August 2016, 16:10:59 UTC
cfd40fd Matt Caswell30 June 2016, 14:06:27 UTCPrevent DTLS Finished message injection Follow on from CVE-2016-2179 The investigation and analysis of CVE-2016-2179 highlighted a related flaw. This commit fixes a security "near miss" in the buffered message handling code. Ultimately this is not currently believed to be exploitable due to the reasons outlined below, and therefore there is no CVE for this on its own. The issue this commit fixes is a MITM attack where the attacker can inject a Finished message into the handshake. In the description below it is assumed that the attacker injects the Finished message for the server to receive it. The attack could work equally well the other way around (i.e where the client receives the injected Finished message). The MITM requires the following capabilities: - The ability to manipulate the MTU that the client selects such that it is small enough for the client to fragment Finished messages. - The ability to selectively drop and modify records sent from the client - The ability to inject its own records and send them to the server The MITM forces the client to select a small MTU such that the client will fragment the Finished message. Ideally for the attacker the first fragment will contain all but the last byte of the Finished message, with the second fragment containing the final byte. During the handshake and prior to the client sending the CCS the MITM injects a plaintext Finished message fragment to the server containing all but the final byte of the Finished message. The message sequence number should be the one expected to be used for the real Finished message. OpenSSL will recognise that the received fragment is for the future and will buffer it for later use. After the client sends the CCS it then sends its own Finished message in two fragments. The MITM causes the first of these fragments to be dropped. The OpenSSL server will then receive the second of the fragments and reassemble the complete Finished message consisting of the MITM fragment and the final byte from the real client. The advantage to the attacker in injecting a Finished message is that this provides the capability to modify other handshake messages (e.g. the ClientHello) undetected. A difficulty for the attacker is knowing in advance what impact any of those changes might have on the final byte of the handshake hash that is going to be sent in the "real" Finished message. In the worst case for the attacker this means that only 1 in 256 of such injection attempts will succeed. It may be possible in some situations for the attacker to improve this such that all attempts succeed. For example if the handshake includes client authentication then the final message flight sent by the client will include a Certificate. Certificates are ASN.1 objects where the signed portion is DER encoded. The non-signed portion could be BER encoded and so the attacker could re-encode the certificate such that the hash for the whole handshake comes to a different value. The certificate re-encoding would not be detectable because only the non-signed portion is changed. As this is the final flight of messages sent from the client the attacker knows what the complete hanshake hash value will be that the client will send - and therefore knows what the final byte will be. Through a process of trial and error the attacker can re-encode the certificate until the modified handhshake also has a hash with the same final byte. This means that when the Finished message is verified by the server it will be correct in all cases. In practice the MITM would need to be able to perform the same attack against both the client and the server. If the attack is only performed against the server (say) then the server will not detect the modified handshake, but the client will and will abort the connection. Fortunately, although OpenSSL is vulnerable to Finished message injection, it is not vulnerable if *both* client and server are OpenSSL. The reason is that OpenSSL has a hard "floor" for a minimum MTU size that it will never go below. This minimum means that a Finished message will never be sent in a fragmented form and therefore the MITM does not have one of its pre-requisites. Therefore this could only be exploited if using OpenSSL and some other DTLS peer that had its own and separate Finished message injection flaw. The fix is to ensure buffered messages are cleared on epoch change. Reviewed-by: Richard Levitte <levitte@openssl.org>22 August 2016, 10:03:14 UTC
00a4c14 Matt Caswell30 June 2016, 12:17:08 UTCFix DTLS buffered message DoS attack DTLS can handle out of order record delivery. Additionally since handshake messages can be bigger than will fit into a single packet, the messages can be fragmented across multiple records (as with normal TLS). That means that the messages can arrive mixed up, and we have to reassemble them. We keep a queue of buffered messages that are "from the future", i.e. messages we're not ready to deal with yet but have arrived early. The messages held there may not be full yet - they could be one or more fragments that are still in the process of being reassembled. The code assumes that we will eventually complete the reassembly and when that occurs the complete message is removed from the queue at the point that we need to use it. However, DTLS is also tolerant of packet loss. To get around that DTLS messages can be retransmitted. If we receive a full (non-fragmented) message from the peer after previously having received a fragment of that message, then we ignore the message in the queue and just use the non-fragmented version. At that point the queued message will never get removed. Additionally the peer could send "future" messages that we never get to in order to complete the handshake. Each message has a sequence number (starting from 0). We will accept a message fragment for the current message sequence number, or for any sequence up to 10 into the future. However if the Finished message has a sequence number of 2, anything greater than that in the queue is just left there. So, in those two ways we can end up with "orphaned" data in the queue that will never get removed - except when the connection is closed. At that point all the queues are flushed. An attacker could seek to exploit this by filling up the queues with lots of large messages that are never going to be used in order to attempt a DoS by memory exhaustion. I will assume that we are only concerned with servers here. It does not seem reasonable to be concerned about a memory exhaustion attack on a client. They are unlikely to process enough connections for this to be an issue. A "long" handshake with many messages might be 5 messages long (in the incoming direction), e.g. ClientHello, Certificate, ClientKeyExchange, CertificateVerify, Finished. So this would be message sequence numbers 0 to 4. Additionally we can buffer up to 10 messages in the future. Therefore the maximum number of messages that an attacker could send that could get orphaned would typically be 15. The maximum size that a DTLS message is allowed to be is defined by max_cert_list, which by default is 100k. Therefore the maximum amount of "orphaned" memory per connection is 1500k. Message sequence numbers get reset after the Finished message, so renegotiation will not extend the maximum number of messages that can be orphaned per connection. As noted above, the queues do get cleared when the connection is closed. Therefore in order to mount an effective attack, an attacker would have to open many simultaneous connections. Issue reported by Quan Luo. CVE-2016-2179 Reviewed-by: Richard Levitte <levitte@openssl.org>22 August 2016, 10:03:14 UTC
f3e01c8 Kurt Roeckx06 August 2016, 17:16:00 UTCFix off by 1 in ASN1_STRING_set() Reviewed-by: Rich Salz <rsalz@openssl.org> MR: #3176 (cherry picked from commit a73be798ced572a988d455d961a2387f6eccb549)20 August 2016, 17:02:12 UTC
19fca4c Rich Salz13 August 2016, 14:47:50 UTCRT3940: For now, just document the issue. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 2a9afa4046592d44af84644cd89fe1a0d6d46889)19 August 2016, 15:45:57 UTC
5802758 Matt Caswell17 August 2016, 16:55:36 UTCUpdate function error code A function error code needed updating due to merge issues. Reviewed-by: Richard Levitte <levitte@openssl.org>19 August 2016, 13:05:09 UTC
b77ab01 Matt Caswell05 July 2016, 11:04:37 UTCFix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>19 August 2016, 13:04:56 UTC
fa75569 Matt Caswell05 July 2016, 10:46:26 UTCFix DTLS unprocessed records bug During a DTLS handshake we may get records destined for the next epoch arrive before we have processed the CCS. In that case we can't decrypt or verify the record yet, so we buffer it for later use. When we do receive the CCS we work through the queue of unprocessed records and process them. Unfortunately the act of processing wipes out any existing packet data that we were still working through. This includes any records from the new epoch that were in the same packet as the CCS. We should only process the buffered records if we've not got any data left. Reviewed-by: Richard Levitte <levitte@openssl.org>19 August 2016, 13:04:44 UTC
6c858db Richard Levitte16 August 2016, 12:14:33 UTCmake update to have PEM_R_HEADER_TOO_LONG defined (cherry picked from commit a1be17a72f6e0fe98275dc113cddd799bf55df44) Conflicts: crypto/pem/pem_err.c Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Stephen Henson <steve@openssl.org>16 August 2016, 12:54:46 UTC
17603dd Dr. Stephen Henson15 August 2016, 15:52:21 UTCLimit reads in do_b2i_bio() Apply a limit to the maximum blob length which can be read in do_d2i_bio() to avoid excessive allocation. Thanks to Shi Lei for reporting this. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 66bcba145740e4f1210499ba6e5033035a2a4647)15 August 2016, 23:28:22 UTC
28a8963 Dr. Stephen Henson05 August 2016, 13:26:03 UTCCheck for errors in BN_bn2dec() If an oversize BIGNUM is presented to BN_bn2dec() it can cause BN_div_word() to fail and not reduce the value of 't' resulting in OOB writes to the bn_data buffer and eventually crashing. Fix by checking return value of BN_div_word() and checking writes don't overflow buffer. Thanks to Shi Lei for reporting this bug. CVE-2016-2182 Reviewed-by: Tim Hudson <tjh@openssl.org> (cherry picked from commit 07bed46f332fce8c1d157689a2cdf915a982ae34) Conflicts: crypto/bn/bn_print.c15 August 2016, 23:23:30 UTC
ff0571b Dr. Stephen Henson05 August 2016, 13:33:03 UTCCheck for errors in a2d_ASN1_OBJECT() Check for error return in BN_div_word(). Reviewed-by: Tim Hudson <tjh@openssl.org> (cherry picked from commit 8b9afbc0fc7f8be0049d389d34d9416fa377e2aa)15 August 2016, 23:23:07 UTC
7a49798 Dr. Stephen Henson05 August 2016, 16:59:32 UTCSanity check input length in OPENSSL_uni2asc(). Thanks to Hanno Böck for reporting this bug. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 39a43280316f1b9c45be5ac5b04f4f5c3f923686) Conflicts: crypto/pkcs12/p12_utl.c05 August 2016, 18:01:55 UTC
d23de0b Dr. Stephen Henson05 August 2016, 15:21:26 UTCLeak fixes. Fix error path leaks in a2i_ASN1_STRING(), a2i_ASN1_INTEGER() and a2i_ASN1_ENUMERATED(). Thanks to Shi Lei for reporting these issues. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit e1be1dce7722ee40ced16b1b91d5e1b9fce13d08)05 August 2016, 17:06:56 UTC
3c39313 Kurt Roeckx16 July 2016, 14:56:54 UTCReturn error when trying to print invalid ASN1 integer GH: #1322 Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Stephen Henson <steve@openssl.org> (cherry picked from commit 32baafb2f6fb2a424824df08232d86765f554880)04 August 2016, 21:23:22 UTC
a199e0c Dr. Stephen Henson04 August 2016, 14:00:26 UTCLimit recursion depth in old d2i_ASN1_bytes function Thanks to Shi Lei for reporting this bug. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 81f69e5b69b8e87ca5d7080ab643ebda7808542c)04 August 2016, 21:12:59 UTC
6592de7 Dr. Stephen Henson04 August 2016, 12:54:51 UTCCheck for overflows in i2d_ASN1_SET() Thanks to Shi Lei for reporting this issue. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit af601b83198771a4ad54ac0f415964b90aab4b5f)04 August 2016, 16:43:57 UTC
5db2a57 Dr. Stephen Henson02 August 2016, 22:53:41 UTCCalculate sequence length properly. Use correct length in old ASN.1 indefinite length sequence decoder (only used by SSL_SESSION). This bug was discovered by Hanno Böck using libfuzzer. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 436dead2e2a157fa501a7538a77b6078391b477f)03 August 2016, 01:36:08 UTC
c648bdc Dr. Stephen Henson02 August 2016, 22:41:45 UTCinclude <limits.h> Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 134ab5139a8d41455a81d9fcc31b3edb8a4b2f5c)02 August 2016, 23:10:26 UTC
7149c70 Dr. Stephen Henson01 August 2016, 23:30:47 UTCCheck for overflows in ASN1_object_size(). Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit e9f17097e9fbba3e7664cd67e54eebf2bd438863)02 August 2016, 19:55:06 UTC
e3db6f1 Dr. Stephen Henson01 August 2016, 23:45:31 UTCCheck for overlows and error return from ASN1_object_size() Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 56f9953c846204cb3251ab27605e403c7444fd72)02 August 2016, 19:55:06 UTC
6adf409 Dr. Stephen Henson21 July 2016, 14:24:16 UTCFix OOB read in TS_OBJ_print_bio(). TS_OBJ_print_bio() misuses OBJ_txt2obj: it should print the result as a null terminated buffer. The length value returned is the total length the complete text reprsentation would need not the amount of data written. CVE-2016-2180 Thanks to Shi Lei for reporting this bug. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 0ed26acce328ec16a3aa635f1ca37365e8c7403a)22 July 2016, 14:17:38 UTC
beaa2c0 Matt Caswell24 June 2016, 22:37:27 UTCConvert memset calls to OPENSSL_cleanse Ensure things really do get cleared when we intend them to. Addresses an OCAP Audit issue. Reviewed-by: Andy Polyakov <appro@openssl.org> (cherry picked from commit cb5ebf961333896776fbce10ef88c2af7bec8aea)30 June 2016, 14:56:16 UTC
08327bf Richard Levitte19 June 2016, 08:55:43 UTCAllow proxy certs to be present when verifying a chain Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 6ad8c48291622a6ccc51489b9a230c9a05ca5614)29 June 2016, 23:01:38 UTC
f7c9528 Richard Levitte19 June 2016, 08:55:29 UTCFix proxy certificate pathlength verification While travelling up the certificate chain, the internal proxy_path_length must be updated with the pCPathLengthConstraint value, or verification will not work properly. This corresponds to RFC 3820, 4.1.4 (a). Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 30aeb3128199c15760a785d88a4eda9e156d5af6)29 June 2016, 23:00:26 UTC
26576cf Richard Levitte19 June 2016, 08:55:16 UTCCheck that the subject name in a proxy cert complies to RFC 3820 The subject name MUST be the same as the issuer name, with a single CN entry added. RT#1852 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 338fb1688fbfb7efe0bdd475b01791a6de5ef94b)29 June 2016, 23:00:19 UTC
05200ee Matt Caswell25 April 2016, 16:06:56 UTCChange usage of RAND_pseudo_bytes to RAND_bytes RAND_pseudo_bytes() allows random data to be returned even in low entropy conditions. Sometimes this is ok. Many times it is not. For the avoidance of any doubt, replace existing usage of RAND_pseudo_bytes() with RAND_bytes(). Reviewed-by: Rich Salz <rsalz@openssl.org>27 June 2016, 14:02:34 UTC
3681a45 Matt Caswell07 June 2016, 08:12:51 UTCMore fix DSA, preserve BN_FLG_CONSTTIME The previous "fix" still left "k" exposed to constant time problems in the later BN_mod_inverse() call. Ensure both k and kq have the BN_FLG_CONSTTIME flag set at the earliest opportunity after creation. CVE-2016-2178 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit b7d0f2834e139a20560d64c73e2565e93715ce2b)07 June 2016, 14:23:41 UTC
d168705 Cesar Pereida23 May 2016, 09:45:25 UTCFix DSA, preserve BN_FLG_CONSTTIME Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key. CVE-2016-2178 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 621eaf49a289bfac26d4cbcdb7396e796784c534)06 June 2016, 10:31:36 UTC
ac29a0f Matt Caswell03 June 2016, 16:12:08 UTCUpdate CONTRIBUTING Fix typos and clarify a few things in the CONTRIBUTING file. Reviewed-by: Rich Salz <rsalz@openssl.org>03 June 2016, 16:12:39 UTC
6f35f6d Matt Caswell05 May 2016, 10:10:26 UTCAvoid some undefined pointer arithmetic A common idiom in the codebase is: if (p + len > limit) { return; /* Too long */ } Where "p" points to some malloc'd data of SIZE bytes and limit == p + SIZE "len" here could be from some externally supplied data (e.g. from a TLS message). The rules of C pointer arithmetic are such that "p + len" is only well defined where len <= SIZE. Therefore the above idiom is actually undefined behaviour. For example this could cause problems if some malloc implementation provides an address for "p" such that "p + len" actually overflows for values of len that are too big and therefore p + len < limit! Issue reported by Guido Vranken. CVE-2016-2177 Reviewed-by: Rich Salz <rsalz@openssl.org>01 June 2016, 13:25:03 UTC
3d4f83a Viktor Dukhovni17 May 2016, 22:25:40 UTCEnsure verify error is set when X509_verify_cert() fails Set ctx->error = X509_V_ERR_OUT_OF_MEM when verificaiton cannot continue due to malloc failure. Similarly for issuer lookup failures and caller errors (bad parameters or invalid state). Also, when X509_verify_cert() returns <= 0 make sure that the verification status does not remain X509_V_OK, as a last resort set it it to X509_V_ERR_UNSPECIFIED, just in case some code path returns an error without setting an appropriate value of ctx->error. Add new and some missing error codes to X509 error -> SSL alert switch. Reviewed-by: Rich Salz <rsalz@openssl.org>26 May 2016, 20:36:49 UTC
aed4d5b Viktor Dukhovni17 May 2016, 01:38:03 UTCClarify negative return from X509_verify_cert() Reviewed-by: Rich Salz <rsalz@openssl.org>26 May 2016, 20:36:35 UTC
051b960 Matt Caswell25 April 2016, 15:22:31 UTCFix error return value in SRP functions The functions SRP_Calc_client_key() and SRP_Calc_server_key() were incorrectly returning a valid pointer in the event of error. Issue reported by Yuan Jochen Kang Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit 308ff28673ae1a4a1b346761224b4a8851d41f58)23 May 2016, 23:05:54 UTC
eea595f Matt Caswell25 April 2016, 15:50:59 UTCCheck that the obtained public key is valid In the X509 app check that the obtained public key is valid before we attempt to use it. Issue reported by Yuan Jochen Kang. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>19 May 2016, 20:08:27 UTC
bdbfb84 Rich Salz11 May 2016, 20:46:44 UTCRecommend GH over RT, per team vote. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit c393a5de99b5c565a124af8f69936dadde77184f)11 May 2016, 20:47:56 UTC
24762de Dr. Stephen Henson11 May 2016, 17:00:52 UTCUpdate S/MIME certificates. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>11 May 2016, 17:00:52 UTC
6ec73ea Dr. Stephen Henson08 May 2016, 23:06:02 UTCOnly call FIPS_update, FIPS_final in FIPS mode. RT#3826 Reviewed-by: Tim Hudson <tjh@openssl.org> (cherry picked from commit 2b4825d0bb6057e44717007a54797df72babdb7e)09 May 2016, 01:10:28 UTC
0377ad3 Dr. Stephen Henson06 May 2016, 02:46:09 UTCConstify PKCS12_newpass() PR#4449 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit b1f8ba4dc7032a061d60b960c393178263e4a471)06 May 2016, 20:53:09 UTC
5255b49 Dr. Stephen Henson05 May 2016, 14:37:23 UTCTidy up PKCS12_newpass() fix memory leaks. PR#4466 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 06227924ad77fee9ead79189328aebf078c37add)06 May 2016, 20:52:13 UTC
4d71891 Dr. Stephen Henson06 May 2016, 18:27:49 UTCOnly set CMS parameter when encrypting Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 708cf5ded249f871fcd5e3de27d9281b1f37ae71)06 May 2016, 20:14:19 UTC
b0e1362 Dr. Stephen Henson05 May 2016, 21:17:05 UTCUse default ASN.1 for SEED. The default ASN.1 handling can be used for SEED. This also makes CMS work with SEED. PR#4504 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit c0aa8c274843c5b8a70d70fc05d71fa3dfd510db)05 May 2016, 23:03:28 UTC
852034b Dr. Stephen Henson21 March 2016, 15:48:51 UTCAlways try to set ASN.1 parameters for CMS. Try to set the ASN.1 parameters for CMS encryption even if the IV length is zero as the underlying cipher should still set the type. This will correctly result in errors if an attempt is made to use an unsupported cipher type. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 3fd60dc42288591737a35a90368d72dbd00fdef8) Conflicts: crypto/cms/cms_enc.c05 May 2016, 22:56:17 UTC
b583c1b Dr. Stephen Henson04 May 2016, 15:09:06 UTCFix name length limit check. The name length limit check in x509_name_ex_d2i() includes the containing structure as well as the actual X509_NAME. This will cause large CRLs to be rejected. Fix by limiting the length passed to ASN1_item_ex_d2i() which will then return an error if the passed X509_NAME exceeds the length. RT#4531 Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 4e0d184ac1dde845ba9574872e2ae5c903c81dff)04 May 2016, 16:41:20 UTC
28dab7c Dr. Stephen Henson03 May 2016, 14:05:31 UTCFix double free in d2i_PrivateKey(). RT#4527 Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 3340e8bb186f689df5720352f65a9c0c42b6046b)04 May 2016, 12:00:18 UTC
c3011e3 Dr. Stephen Henson03 May 2016, 14:21:41 UTCadd documentation Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit b1b3e14fbeb373a288ba20402600e071e6f402f8)04 May 2016, 12:00:17 UTC
c33e689 Matt Caswell03 May 2016, 13:50:37 UTCPrepare for 1.0.1u-dev Reviewed-by: Rich Salz <rsalz@openssl.org>03 May 2016, 13:50:37 UTC
3d2e575 Matt Caswell03 May 2016, 13:49:52 UTCPrepare for 1.0.1t release Reviewed-by: Rich Salz <rsalz@openssl.org>03 May 2016, 13:49:52 UTC
289cc05 Matt Caswell03 May 2016, 13:49:52 UTCmake update Reviewed-by: Rich Salz <rsalz@openssl.org>03 May 2016, 13:49:52 UTC
0e6b8bf Matt Caswell03 May 2016, 08:37:23 UTCUpdate CHANGES and NEWS for the new release Reviewed-by: Richard Levitte <levitte@openssl.org>03 May 2016, 12:20:26 UTC
f5da52e Dr. Stephen Henson15 April 2016, 01:37:09 UTCFix ASN1_INTEGER handling. Only treat an ASN1_ANY type as an integer if it has the V_ASN1_INTEGER tag: V_ASN1_NEG_INTEGER is an internal only value which is never used for on the wire encoding. Thanks to David Benjamin <davidben@google.com> for reporting this bug. This was found using libFuzzer. RT#4364 (part)CVE-2016-2108. Reviewed-by: Emilia Käsper <emilia@openssl.org>03 May 2016, 12:06:36 UTC
4159f31 Kurt Roeckx16 April 2016, 21:08:56 UTCCheck that we have enough padding characters. Reviewed-by: Emilia Käsper <emilia@openssl.org> CVE-2016-2107 MR: #257203 May 2016, 12:06:36 UTC
e903aaf Matt Caswell03 May 2016, 11:45:45 UTCRemove some documentation for functions not in 1.0.x A few functions in the recently added EVP_EncodeInit docs don't apply to the 1.0.x branches. Reviewed-by: Richard Levitte <levitte@openssl.org>03 May 2016, 11:54:06 UTC
fec6d1e Matt Caswell25 April 2016, 10:54:30 UTCAdd documentation for EVP_EncodeInit() and similar functions Reviewed-by: Richard Levitte <levitte@openssl.org>03 May 2016, 10:54:00 UTC
5d20e98 Matt Caswell25 April 2016, 08:06:29 UTCEnsure EVP_EncodeUpdate handles an output length that is too long With the EVP_EncodeUpdate function it is the caller's responsibility to determine how big the output buffer should be. The function writes the amount actually used to |*outl|. However this could go negative with a sufficiently large value for |inl|. We add a check for this error condition. Reviewed-by: Richard Levitte <levitte@openssl.org>03 May 2016, 10:52:53 UTC
5b81448 Matt Caswell04 March 2016, 10:17:17 UTCAvoid overflow in EVP_EncodeUpdate An overflow can occur in the EVP_EncodeUpdate function which is used for Base64 encoding of binary data. If an attacker is able to supply very large amounts of input data then a length check can overflow resulting in a heap corruption. Due to the very large amounts of data involved this will most likely result in a crash. Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the PEM_write_bio* family of functions. These are mainly used within the OpenSSL command line applications, so any application which processes data from an untrusted source and outputs it as a PEM file should be considered vulnerable to this issue. User applications that call these APIs directly with large amounts of untrusted data may also be vulnerable. Issue reported by Guido Vranken. CVE-2016-2105 Reviewed-by: Richard Levitte <levitte@openssl.org>03 May 2016, 10:52:53 UTC
2919516 Matt Caswell28 April 2016, 09:46:55 UTCPrevent EBCDIC overread for very long strings ASN1 Strings that are over 1024 bytes can cause an overread in applications using the X509_NAME_oneline() function on EBCDIC systems. This could result in arbitrary stack data being returned in the buffer. Issue reported by Guido Vranken. CVE-2016-2176 Reviewed-by: Andy Polyakov <appro@openssl.org>03 May 2016, 09:28:00 UTC
56ea224 Matt Caswell03 March 2016, 23:36:23 UTCFix encrypt overflow An overflow can occur in the EVP_EncryptUpdate function. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate with a partial block then a length check can overflow resulting in a heap corruption. Following an analysis of all OpenSSL internal usage of the EVP_EncryptUpdate function all usage is one of two forms. The first form is like this: EVP_EncryptInit() EVP_EncryptUpdate() i.e. where the EVP_EncryptUpdate() call is known to be the first called function after an EVP_EncryptInit(), and therefore that specific call must be safe. The second form is where the length passed to EVP_EncryptUpdate() can be seen from the code to be some small value and therefore there is no possibility of an overflow. Since all instances are one of these two forms, I believe that there can be no overflows in internal code due to this problem. It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate() in certain code paths. Also EVP_CipherUpdate() is a synonym for EVP_EncryptUpdate(). Therefore I have checked all instances of these calls too, and came to the same conclusion, i.e. there are no instances in internal usage where an overflow could occur. This could still represent a security issue for end user code that calls this function directly. CVE-2016-2106 Issue reported by Guido Vranken. Reviewed-by: Tim Hudson <tjh@openssl.org> (cherry picked from commit 3f3582139fbb259a1c3cbb0a25236500a409bf26)03 May 2016, 08:03:16 UTC
1d29506 Dr. Stephen Henson02 May 2016, 16:33:50 UTCFix i2d_X509_AUX: pp can be NULL. Reported by David Benjamin Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit 05aef4bbdbc18e7b9490512cdee41e8a608bcc0e)02 May 2016, 21:50:19 UTC
66ce286 Dr. Stephen Henson27 April 2016, 19:27:41 UTCDon't free ret->data if malloc fails. Issue reported by Guido Vranken. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 64eaf6c928f4066d62aa86f805796ef05bd0b1cc)29 April 2016, 20:43:12 UTC
1c81a59 Dr. Stephen Henson28 April 2016, 18:45:44 UTCAdd checks to X509_NAME_oneline() Sanity check field lengths and sums to avoid potential overflows and reject excessively large X509_NAME structures. Issue reported by Guido Vranken. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 9b08619cb45e75541809b1154c90e1a00450e537) Conflicts: crypto/x509/x509.h crypto/x509/x509_err.c29 April 2016, 18:55:56 UTC
0b34cf8 Dr. Stephen Henson28 April 2016, 12:09:27 UTCSanity check buffer length. Reject zero length buffers passed to X509_NAME_onelne(). Issue reported by Guido Vranken. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit b33d1141b6dcce947708b984c5e9e91dad3d675d)29 April 2016, 18:54:06 UTC
53d6c14 Dr. Stephen Henson28 April 2016, 11:55:29 UTCAdd size limit to X509_NAME structure. This adds an explicit limit to the size of an X509_NAME structure. Some part of OpenSSL (e.g. TLS) already effectively limit the size due to restrictions on certificate size. Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 295f3a24919157e2f9021d0b1709353710ad63db)29 April 2016, 18:53:47 UTC
6dfa55a Dr. Stephen Henson23 April 2016, 12:33:05 UTCReject inappropriate private key encryption ciphers. The traditional private key encryption algorithm doesn't function properly if the IV length of the cipher is zero. These ciphers (e.g. ECB mode) are not suitable for private key encryption anyway. Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit d78df5dfd650e6de159a19a033513481064644f5)27 April 2016, 23:07:20 UTC
a04d08f Matt Caswell25 April 2016, 15:05:55 UTCEnsure we check i2d_X509 return val The i2d_X509() function can return a negative value on error. Therefore we should make sure we check it. Issue reported by Yuan Jochen Kang. Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit 446ba8de9af9aa4fa3debc7c76a38f4efed47a62)26 April 2016, 13:39:56 UTC
1ee4541 Matt Caswell25 April 2016, 16:45:11 UTCFix a signed/unsigned warning This causes a compilation failure when using --strict-warnings in 1.0.2 and 1.0.1 Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 0ca67644ddedfd656d43a6639d89a6236ff64652)25 April 2016, 18:47:18 UTC
184ebf0 Rich Salz25 April 2016, 12:56:54 UTCFix NULL deref in apps/pkcs7 Thanks to Brian Carpenter for finding and reporting this. Reviewed-by: Emilia Käsper <emilia@openssl.org> (cherry picked from commit 79356a83b78a2d936dcd022847465d9ebf6c67b1)25 April 2016, 15:46:52 UTC
697283b Viktor Dukhovni20 April 2016, 02:23:24 UTCFix buffer overrun in ASN1_parse(). Backport of commits: 79c7f74d6cefd5d32fa20e69195ad3de834ce065 bdcd660e33710079b495cf5cc6a1aaa5d2dcd317 from master. Reviewed-by: Matt Caswell <matt@openssl.org>23 April 2016, 04:46:32 UTC
3d41105 Dr. Stephen Henson11 April 2016, 12:57:20 UTCHarden ASN.1 BIO handling of large amounts of data. If the ASN.1 BIO is presented with a large length field read it in chunks of increasing size checking for EOF on each read. This prevents small files allocating excessive amounts of data. CVE-2016-2109 Thanks to Brian Carpenter for reporting this issue. Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit c62981390d6cf9e3d612c489b8b77c2913b25807)22 April 2016, 23:28:06 UTC
7a43389 David Benjamin14 March 2016, 19:03:07 UTCFix memory leak on invalid CertificateRequest. Free up parsed X509_NAME structure if the CertificateRequest message contains excess data. The security impact is considered insignificant. This is a client side only leak and a large number of connections to malicious servers would be needed to have a significant impact. This was found by libFuzzer. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Stephen Henson <steve@openssl.org> (cherry picked from commit ec66c8c98881186abbb4a7ddd6617970f1ee27a7)07 April 2016, 18:27:45 UTC
f4bed7c Dr. Stephen Henson26 March 2016, 15:00:53 UTCFix FIPS SSLv2 test Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 21211ade53f92629250bbea5e37d9179a31d3be2)26 March 2016, 16:02:39 UTC
f160807 Matt Caswell17 March 2016, 12:55:02 UTCFix the no-comp option for Windows no-comp on Windows was not actually suppressing compilation of the code, although it was suppressing its use. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit a6406c95984a1009f5676bbcf60cc0d6db107af4)18 March 2016, 12:17:06 UTC
4275ee3 Matt Caswell15 March 2016, 11:51:48 UTCAdd a check for a failed malloc Ensure we check for a NULL return from OPENSSL_malloc Issue reported by Guido Vranken. Reviewed-by: Richard Levitte <levitte@openssl.org>18 March 2016, 11:59:11 UTC
d31b251 Matt Caswell15 March 2016, 11:38:56 UTCEnsure that memory allocated for the ticket is freed If a call to EVP_DecryptUpdate fails then a memory leak could occur. Ensure that the memory is freed appropriately. Issue reported by Guido Vranken. Reviewed-by: Richard Levitte <levitte@openssl.org>18 March 2016, 11:59:11 UTC
4161523 Matt Caswell14 March 2016, 17:06:19 UTCFix a potential double free in EVP_DigestInit_ex There is a potential double free in EVP_DigestInit_ex. This is believed to be reached only as a result of programmer error - but we should fix it anyway. Issue reported by Guido Vranken. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit ffe9150b1508a0ffc9e724f975691f24eb045c05)18 March 2016, 11:44:47 UTC
6629966 Kurt Roeckx09 March 2016, 17:10:52 UTCAdd no-ssl2-method Reviewed-by: Viktor Dukhovni <viktor@openssl.org> MR: #2341 (cherry picked from commit 4256957570a233ed4e9840353e95e623dfd62086)14 March 2016, 20:17:18 UTC
03c71b8 Viktor Dukhovni08 March 2016, 20:30:27 UTCexpose SSLv2 method prototypes Reviewed-by: Kurt Roeckx <kurt@openssl.org>09 March 2016, 08:13:06 UTC
5bac9d4 Viktor Dukhovni07 March 2016, 21:10:38 UTCRetain SSLv2 methods as functions that return NULL This improves ABI compatibility when symbol resolution is not lazy. Reviewed-by: Richard Levitte <levitte@openssl.org>08 March 2016, 14:08:28 UTC
a159719 Andy Polyakov04 March 2016, 10:39:11 UTCbn/asm/x86[_64]-mont*.pl: complement alloca with page-walking. Some OSes, *cough*-dows, insist on stack being "wired" to physical memory in strictly sequential manner, i.e. if stack allocation spans two pages, then reference to farmost one can be punishable by SEGV. But page walking can do good even on other OSes, because it guarantees that villain thread hits the guard page before it can make damage to innocent one... Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit adc4f1fc25b2cac90076f1e1695b05b7aeeae501) Resolved conflicts: crypto/bn/asm/x86_64-mont.pl crypto/bn/asm/x86_64-mont5.pl Reviewed-by: Richard Levitte <levitte@openssl.org>07 March 2016, 21:16:11 UTC
6e7a1f3 Kurt Roeckx10 January 2016, 12:23:43 UTCRemove LOW from the default Reviewed-by: Viktor Dukhovni <viktor@openssl.org> (cherry picked from commit 29cce508972f61511318bf8cf7011fae027cddb2)07 March 2016, 17:57:40 UTC
0199251 Dr. Stephen Henson04 March 2016, 18:04:46 UTCDon't shift serial number into sign bit Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 01c32b5e448f6d42a23ff16bdc6bb0605287fa6f)07 March 2016, 15:19:58 UTC
298d823 Dr. Stephen Henson03 March 2016, 23:37:36 UTCSanity check PVK file fields. PVK files with abnormally large length or salt fields can cause an integer overflow which can result in an OOB read and heap corruption. However this is an rarely used format and private key files do not normally come from untrusted sources the security implications not significant. Fix by limiting PVK length field to 100K and salt to 10K: these should be more than enough to cover any files encountered in practice. Issue reported by Guido Vranken. Reviewed-by: Rich Salz <rsalz@openssl.org> (cherry picked from commit 5f57abe2b150139b8b057313d52b1fe8f126c952)04 March 2016, 01:26:13 UTC
7315877 Matt Caswell01 March 2016, 13:42:02 UTCPrepare for 1.0.1t-dev Reviewed-by: Richard Levitte <levitte@openssl.org>01 March 2016, 13:42:02 UTC
57ac73f Matt Caswell01 March 2016, 13:40:46 UTCPrepare for 1.0.1s release Reviewed-by: Richard Levitte <levitte@openssl.org>01 March 2016, 13:40:46 UTC
5d2b93a Matt Caswell01 March 2016, 13:40:45 UTCmake update Reviewed-by: Richard Levitte <levitte@openssl.org>01 March 2016, 13:40:45 UTC
f588db9 Matt Caswell01 March 2016, 12:08:33 UTCEnsure mk1mf.pl is aware of no-weak-ssl-ciphers option Update mk1mf.pl to properly handle no-weak-ssl-ciphers Reviewed-by: Richard Levitte <levitte@openssl.org>01 March 2016, 12:42:12 UTC
8954b54 Matt Caswell01 March 2016, 11:00:48 UTCUpdate CHANGES and NEWS for new release Reviewed-by: Richard Levitte <levitte@openssl.org>01 March 2016, 11:51:00 UTC
back to top