- 24 Aug, 2016 2 commits
-
-
Rich Salz authored
Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
Emilia Käsper <emilia@openssl.org>
-
Matt Caswell authored
Use a ciphersuite in dtlstest that is not affected by no-* options. Backport of commit fe34735c . Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
- 23 Aug, 2016 1 commit
-
-
Dr. Stephen Henson authored
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>
-
- 22 Aug, 2016 12 commits
-
-
Richard Levitte authored
We don't really have a mechanism to include other object files into a given test program. For now, a simple hack in mk1mf.pl will do. RT#4653 Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
David Benjamin authored
a03f81f4 added a malloc failure check to EVP_PKEY_keygen, but there already was one. Signed-off-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Rich Salz <rsalz@openssl.org> GH: #1473
-
Kazuki Yamaguchi authored
Fix an off by one error in the overflow check added by 07bed46f ("Check for errors in BN_bn2dec()"). Reviewed-by:
Stephen Henson <steve@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 099e2968)
-
Rich Salz authored
Also, re-organize RSA check to use goto err. Try all checks, not just stopping at first (via Richard Levitte) Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 464d59a5)
-
Richard Levitte authored
Most of the time, this isn't strictly needed. However, in the default extern model (called relaxed refdef), symbols are treated as weak common objects unless they are initialised. The librarian doesn't include weak symbols in the (static) libraries, which renders them invisible when linking a program with said those libraries, which is a problem at times. Using the strict refdef model is much more like standard C on all other platforms, and thereby avoid the issues that come with the relaxed refdef model. Note: this doesn't apply to VAX C. It's possible that this will make OpenSSL building with VAX C difficult some time in the future if it isn't already. However, VAX C is a very old compiler that we don't expect to see too often, as DEC C (a.k.a VMS C) should have replaced it a long time ago. Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Some builds fail otherwise. Reviewed-by:
Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
The following would fail, or rather, freeze: openssl genrsa -out rsa2048.pem 2048 openssl req -x509 -key rsa2048.pem -keyform PEM -out cert.pem In that case, the second command wants to read a certificate request from stdin, because -x509 wasn't fully flagged as being for creating something new. This changes makes it fully flagged. RT#4655 Reviewed-by:
Andy Polyakov <appro@openssl.org>
-
Andy Polyakov authored
Original strategy for page-walking was adjust stack pointer and then touch pages in order. This kind of asks for double-fault, because if touch fails, then signal will be delivered to frame above adjusted stack pointer. But touching pages prior adjusting stack pointer would upset valgrind. As compromise let's adjust stack pointer in pages, touching top of the stack. This still asks for double-fault, but at least prevents corruption of neighbour stack if allocation is to overstep the guard page. Also omit predict-non-taken hints as they reportedly trigger illegal instructions in some VM setups. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 3ba1ef82)
-
Richard Levitte authored
In mempacket_test_read(), we've already fetched the top value of the stack, so when we shift the stack, we don't care for the value. The compiler needs to be told, or it will complain harshly when we tell it to be picky. Reviewed-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 1c288878)
-
Matt Caswell authored
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>
-
Matt Caswell authored
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 messag...
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
- 21 Aug, 2016 3 commits
-
-
Andy Polyakov authored
Thanks to Brian Smith for reporting this. Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Rich Salz authored
Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Rich Salz authored
Reviewed-by:
Dr. Stephen Henson <steve@openssl.org>
-
- 20 Aug, 2016 1 commit
-
-
Kurt Roeckx authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> MR: #3176 (cherry picked from commit a73be798)
-
- 19 Aug, 2016 13 commits
-
-
Rich Salz authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 2a9afa40)
-
Rich Salz authored
RT4386: Add sanity checks for BN_new() RT4384: Missing Sanity Checks for RSA_new_method() RT4384: Missing Sanity Check plus potential NULL pointer deref RT4382: Missing Sanity Check(s) for BUF_strdup() RT4380: Missing Sanity Checks for EVP_PKEY_new() RT4377: Prevent potential NULL pointer dereference RT4375: Missing sanity checks for OPENSSL_malloc() RT4374: Potential for NULL pointer dereferences RT4371: Missing Sanity Check for malloc() RT4370: Potential for NULL pointer dereferences Also expand tabs, make update, typo fix (rsalz) Minor tweak by Paul Dale. Some minor internal review feedback. Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
Reviewed-by:
Matt Caswell <matt@openssl.org>
-
Matt Caswell authored
A function error code needed updating due to merge issues. Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
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>
-
Matt Caswell authored
Injects a record from epoch 1 during epoch 0 handshake, with a record sequence number in the future, to test that the record replay protection feature works as expected. This is described more fully in the next commit. Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
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>
-
Matt Caswell authored
Add a test to inject a record from the next epoch during the handshake and make sure it doesn't get processed immediately. Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Enables the testing of DTLS code in 1.0.2 Reviewed-by:
Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
- make the VMS version of RAND_poll() faster and more secure - avoid pointer size warnings with setvbuf() Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
- 18 Aug, 2016 1 commit
-
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
- 16 Aug, 2016 1 commit
-
-
Richard Levitte authored
Reviewed-by:
Rich Salz <rsalz@openssl.org>
-
- 15 Aug, 2016 3 commits
-
-
Dr. Stephen Henson authored
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 66bcba14)
-
Dr. Stephen Henson authored
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 07bed46f) Conflicts: crypto/bn/bn_print.c
-
Dr. Stephen Henson authored
Check for error return in BN_div_word(). Reviewed-by:
Tim Hudson <tjh@openssl.org> (cherry picked from commit 8b9afbc0)
-
- 11 Aug, 2016 1 commit
-
-
Andy Polyakov authored
RT#4530 Reviewed-by:
Tim Hudson <tjh@openssl.org> (cherry picked from commit 7123aa81)
-
- 05 Aug, 2016 2 commits
-
-
Dr. Stephen Henson authored
Thanks to Hanno Böck for reporting this bug. Reviewed-by:
Rich Salz <rsalz@openssl.org> (cherry picked from commit 39a43280) Conflicts: crypto/pkcs12/p12_utl.c
-
Dr. Stephen Henson authored
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>
-