Matt Caswell [Tue, 5 Jul 2016 11:04:37 +0000 (12:04 +0100)]
Fix 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>
Matt Caswell [Tue, 5 Jul 2016 10:52:43 +0000 (11:52 +0100)]
Add DTLS replay protection test
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 [Tue, 5 Jul 2016 10:46:26 +0000 (11:46 +0100)]
Fix 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>
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.
Richard Levitte [Wed, 3 Aug 2016 14:02:20 +0000 (16:02 +0200)]
Don't check any revocation info on proxy certificates
Because proxy certificates typically come without any CRL information,
trying to check revocation on them will fail. Better not to try
checking such information for them at all.
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.
Todd Short [Tue, 5 Jul 2016 13:59:29 +0000 (09:59 -0400)]
OCSP_request_add0_id() inconsistent error return
There are two failure cases for OCSP_request_add_id():
1. OCSP_ONEREQ_new() failure, where |cid| is not freed
2. sk_OCSP_ONEREQ_push() failure, where |cid| is freed
This changes makes the error behavior consistent, such that |cid| is
not freed when sk_OCSP_ONEREQ_push() fails. OpenSSL only takes
ownership of |cid| when the function succeeds.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1289)
(cherry picked from commit 415e7c488e09119a42be24129e38ddd43524ee06)
Matt Caswell [Tue, 5 Jul 2016 15:56:33 +0000 (16:56 +0100)]
Disallow multiple protocol flags to s_server and s_client
We shouldn't allow both "-tls1" and "-tls1_2", or "-tls1" and "-no_tls1_2".
The only time multiple flags are allowed is where they are all "-no_<prot>".
cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.
Matt Caswell [Fri, 1 Jul 2016 10:58:05 +0000 (11:58 +0100)]
Avoid an overflow in constructing the ServerKeyExchange message
We calculate the size required for the ServerKeyExchange message and then
call BUF_MEM_grow_clean() on the buffer. However we fail to take account of
2 bytes required for the signature algorithm and 2 bytes for the signature
length, i.e. we could overflow by 4 bytes. In reality this won't happen
because the buffer is pre-allocated to a large size that means it should be
big enough anyway.
Andy Polyakov [Thu, 30 Jun 2016 13:57:57 +0000 (15:57 +0200)]
SPARC assembly pack: enforce V8+ ABI constraints.
Even though it's hard to imagine, it turned out that upper half of
arguments passed to V8+ subroutine can be non-zero.
["n" pseudo-instructions, such as srln being srl in 32-bit case and
srlx in 64-bit one, were implemented in binutils 2.10. It's assumed
that Solaris assembler implemented it around same time, i.e. 2000.]
Richard Levitte [Sun, 19 Jun 2016 08:55:29 +0000 (10:55 +0200)]
Fix 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).
Matt Caswell [Mon, 25 Apr 2016 16:06:56 +0000 (17:06 +0100)]
Change 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().
Matt Caswell [Thu, 23 Jun 2016 18:54:06 +0000 (19:54 +0100)]
Fix ASN1_STRING_to_UTF8 could not convert NumericString
tag2nbyte had -1 at 18th position, but underlying ASN1_mbstring_copy
supports NumericString. tag2nbyte is also used in do_print_ex which will
not be broken by setting 1 at 18th position of tag2nbyte
TerminateProcess is asynchronous, so the code as written in the above
commit is not correct (and doesn't even compile at the moment). It is
also probably not needed in the speed case. Reverting in order to figure
out the correct solution.
The selector field could be omitted because it has a DEFAULT value.
In this case *sfld == NULL (sfld can never be NULL). This was not
noticed because this was never used in existing ASN.1 modules.
Matt Caswell [Fri, 10 Jun 2016 13:25:15 +0000 (14:25 +0100)]
Fix seg fault in TS_RESP_verify_response()
The TS_RESP_verify_response() function is used for verifying the response
from a TSA. You can set the provided TS_VERIFY_CTX with different flags
depending on what aspects of the response you wish to verify.
A seg fault will occur if you supply the TS_VFY_SIGNER or TS_VFY_TSA_NAME
flags without also specifying TS_VFY_SIGNATURE.
Matt Caswell [Tue, 31 May 2016 10:28:14 +0000 (11:28 +0100)]
Fix BN_mod_word bug
On systems where we do not have BN_ULLONG (e.g. typically 64 bit systems)
then BN_mod_word() can return incorrect results if the supplied modulus is
too big.
Matt Caswell [Tue, 7 Jun 2016 08:12:51 +0000 (09:12 +0100)]
More 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.
Cesar Pereida [Mon, 23 May 2016 09:45:25 +0000 (12:45 +0300)]
Fix 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>
Matt Caswell [Fri, 3 Jun 2016 20:49:01 +0000 (21:49 +0100)]
Fix documentation error in x509 app certopt flag
According to the x509 man page in the section discussing -certopt it says
that the ca_default option is the same as that used by the ca utility and
(amongst other things) has the effect of suppressing printing of the
signature - but in fact it doesn't. This error seems to have been present
since the documentation was written back in 2001. It never had this effect.
The default config file sets the certopt value to ca_default. The ca utility
takes that and THEN adds additional options to suppress printing of the
signature. So the ca utility DOES suppress printing of the signature - but
it is not as a result of using the ca_default option.
Matt Caswell [Fri, 3 Jun 2016 14:53:54 +0000 (15:53 +0100)]
BIO_printf() can fail to print the last character
If the string to print is exactly 2048 character long (excluding the NULL
terminator) then BIO_printf will chop off the last byte. This is because
it has filled its static buffer but hasn't yet allocated a dynamic buffer.
In cases where we don't have a dynamic buffer we need to truncate but that
is not the case for BIO_printf(). We need to check whether we are able to
have a dynamic buffer buffer deciding to truncate.