This is a follow up to the alternate chains certificate forgery issue
(CVE-2015-1793). That issue is exacerbated in 1.0.1 by a related bug which
means that we *always* check for an alternative chain, even if we have
already found a chain. The code is supposed to stop as soon as it has found
one (and does do in master and 1.0.2).
Reviewed-by: Stephen Henson <steve@openssl.org>
The function X509_verify_cert checks the value of |ctx->chain| at the
beginning, and if it is NULL then it initialises it, along with the value
of ctx->untrusted. The normal way to use X509_verify_cert() is to first
call X509_STORE_CTX_init(); then set up various parameters etc; then call
X509_verify_cert(); then check the results; and finally call
X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
|ctx->chain| to NULL. The only place in the OpenSSL codebase where
|ctx->chain| is set to anything other than a non NULL value is in
X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
non NULL on entry to X509_verify_cert is if one of the following occurs:
1) An application calls X509_verify_cert() twice without re-initialising
in between.
2) An application reaches inside the X509_STORE_CTX structure and changes
the value of |ctx->chain| directly.
With regards to the second of these, we should discount this - it should
not be supported to allow this.
With regards to the first of these, the documentation is not exactly
crystal clear, but the implication is that you must call
X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
to do this then, at best, the results would be undefined.
Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
likely to have unexpected results, and could be dangerous. This commit
changes the behaviour of X509_verify_cert() so that it causes an error if
|ctx->chain| is anything other than NULL (because this indicates that we
have not been initialised properly). It also clarifies the associated
documentation. This is a follow up commit to CVE-2015-1793.
Reviewed-by: Stephen Henson <steve@openssl.org>
This adds a test for CVE-2015-1793. This adds a new test file
verify_extra_test.c, which could form the basis for additional
verification tests.
Reviewed-by: Stephen Henson <steve@openssl.org>
Conflicts:
test/Makefile
During certificate verfification, OpenSSL will attempt to find an
alternative certificate chain if the first attempt to build such a chain
fails. An error in the implementation of this logic can mean that an
attacker could cause certain checks on untrusted certificates to be
bypassed, such as the CA flag, enabling them to use a valid leaf
certificate to act as a CA and "issue" an invalid certificate.
This occurs where at least one cert is added to the first chain from the
trust store, but that chain still ends up being untrusted. In that case
ctx->last_untrusted is decremented in error.
Patch provided by the BoringSSL project.
CVE-2015-1793
Reviewed-by: Stephen Henson <steve@openssl.org>
In CCM mode don't require a tag before initialising decrypt: this allows
the tag length to be set without requiring the tag.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 9cca7be11d)
Construct bio_err and bio_stdout from file handles instead of FILE
pointers, since the latter might not be implemented (when OPENSSL_NO_STDIO
is defined).
Convert all output to use BIO_printf.
Change lh_foo to lh_SSL_SESSION_foo.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit bb8abd6735)
Conflicts:
crypto/threads/mttest.c
Recent HMAC changes broke ABI compatibility due to a new field in HMAC_CTX.
This backs that change out, and does it a different way.
Thanks to Timo Teras for the concept.
Conflicts:
crypto/hmac/hmac.c
Reviewed-by: Richard Levitte <levitte@openssl.org>
Also tighten X509_cmp_time to reject more than three fractional
seconds in the time; and to reject trailing garbage after the offset.
CVE-2015-1789
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Fix loop in do_free_upto if cmsbio is NULL: this will happen when attempting
to verify and a digest is not recognised. Reported by Johannes Bauer.
CVE-2015-1792
Reviewed-by: Matt Caswell <matt@openssl.org>
In the event of an error in the HMAC function, leaks can occur because the
HMAC_CTX does not get cleaned up.
Thanks to the BoringSSL project for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit e43a13c807)
The function EC_POINT_is_on_curve does not return a boolean value.
It returns 1 if the point is on the curve, 0 if it is not, and -1
on error. Many usages within OpenSSL were incorrectly using this
function and therefore not correctly handling error conditions.
With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 68886be7e2)
This fixes a memory leak that can occur whilst duplicating a BIO chain if
the call to CRYPTO_dup_ex_data() fails. It also fixes a second memory leak
where if a failure occurs after successfully creating the first BIO in the
chain, then the beginning of the new chain was not freed.
With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: Stephen Henson <steve@openssl.org>
Conflicts:
crypto/bio/bio_lib.c
BUF_MEM_free() attempts to cleanse memory using memset immediately prior
to a free. This is at risk of being optimised away by the compiler, so
replace with a call to OPENSSL_cleanse() instead.
With thanks to the Open Crypto Audit Project for reporting this issue.
Reviewed-by: Stephen Henson <steve@openssl.org>
Pointed out by Victor Vasiliev (vasilvv@mit.edu) via Adam Langley
(Google).
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 1e4a355dca)
(cherry picked from commit ac32a77cd6)
A BIGNUM can have the value of -0. The function BN_bn2hex fails to account
for this and can allocate a buffer one byte too short in the event of -0
being used, leading to a one byte buffer overrun. All usage within the
OpenSSL library is considered safe. Any security risk is considered
negligible.
With thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke and
Filip Palian for discovering and reporting this issue.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit c56353071d)
Conflicts:
crypto/bn/bn_print.c
objects.pl only looked for a space to see if the name could be
used as a C identifier. Improve the test to match the real C
rules.
Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 591b7aef05)
The members of struct timeval on OpenVMS are unsigned. The logic for
calculating timeouts needs adjusting to deal with this.
RT#3862
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit fc52ac9028)
We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
If BN_rand is called with |bits| set to 1 and |top| set to 1 then a 1 byte
buffer overflow can occur. There are no such instances within the OpenSSL at
the moment.
Thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke, Filip Palian for
discovering and reporting this issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
The functions BN_rshift and BN_lshift shift their arguments to the right or
left by a specified number of bits. Unpredicatable results (including
crashes) can occur if a negative number is supplied for the shift value.
Thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke and Filip Palian
for discovering and reporting this issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 7cc18d8158)
Conflicts:
crypto/bn/bn.h
crypto/bn/bn_err.c
When building a trust chain if the first attempt fails, then try to see if
alternate chains could be constructed that are trusted.
RT3637
RT3621
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
40 bit ciphers are limited to 512 bit RSA, 56 bit ciphers to 1024 bit.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit ac38115c1a)
The big "don't check for NULL" cleanup requires backporting some
of the lowest-level functions to actually do nothing if NULL is
given. This will make it easier to backport fixes to release
branches, where master assumes those lower-level functions are "safe"
This commit addresses those tickets: 3798 3799 3801.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit f34b095fab)
The function obj_cmp() (file crypto/objects/obj_dat.c) can in some
situations call memcmp() with a null pointer and a zero length.
This is invalid behaviour. When compiling openssl with undefined
behaviour sanitizer (add -fsanitize=undefined to compile flags) this
can be seen. One example that triggers this behaviour is the pkcs7
command (but there are others, e.g. I've seen it with the timestamp
function):
apps/openssl pkcs7 -in test/testp7.pem
What happens is that obj_cmp takes objects of the type ASN1_OBJECT and
passes their ->data pointer to memcmp. Zero-sized ASN1_OBJECT
structures can have a null pointer as data.
RT#3816
Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 2b8dc08b74)
Matt's note: I added a call to X509V3err to Kurt's original patch.
RT#3840
Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 344c271eb3)
The problem occurs in EVP_PKEY_sign() when using RSA with X931 padding.
It is only triggered if the RSA key size is smaller than the digest length.
So with SHA512 you can trigger the overflow with anything less than an RSA
512 bit key. I managed to trigger a 62 byte overflow when using a 16 bit RSA
key. This wasn't sufficient to cause a crash, although your mileage may
vary.
In practice RSA keys of this length are never used and X931 padding is very
rare. Even if someone did use an excessively short RSA key, the chances of
them combining that with a longer digest and X931 padding is very
small. For these reasons I do not believe there is a security implication to
this. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3
Solutions) for reporting this issue.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 34166d4189)
