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 9b08619cb4)
Conflicts:
crypto/x509/x509.h
crypto/x509/x509_err.c
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 b33d1141b6)
In X509_cmp, if cert digest is equal, look at DER of the
signed part. This is what master and 1.0.2 already do.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
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>
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>
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
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)
This should be a one off operation (subsequent invokation of the
script should not move them)
This commit is for the 1.0.1 changes
Reviewed-by: Tim Hudson <tjh@openssl.org>
Sometimes it fails to format them very well, and sometimes it corrupts them!
This commit moves some particularly problematic ones.
Conflicts:
crypto/bn/bn.h
crypto/ec/ec_lcl.h
crypto/rsa/rsa.h
demos/engines/ibmca/hw_ibmca.c
ssl/ssl.h
ssl/ssl3.h
Conflicts:
crypto/ec/ec_lcl.h
ssl/tls1.h
Reviewed-by: Tim Hudson <tjh@openssl.org>
indent will not alter them when reformatting comments
(cherry picked from commit 1d97c84351)
Conflicts:
crypto/bn/bn_lcl.h
crypto/bn/bn_prime.c
crypto/engine/eng_all.c
crypto/rc4/rc4_utl.c
crypto/sha/sha.h
ssl/kssl.c
ssl/t1_lib.c
Conflicts:
crypto/rc4/rc4_enc.c
crypto/x509v3/v3_scts.c
crypto/x509v3/v3nametest.c
ssl/d1_both.c
ssl/s3_srvr.c
ssl/ssl.h
ssl/ssl_locl.h
ssl/ssltest.c
ssl/t1_lib.c
Reviewed-by: Tim Hudson <tjh@openssl.org>
By using non-DER or invalid encodings outside the signed portion of a
certificate the fingerprint can be changed without breaking the signature.
Although no details of the signed portion of the certificate can be changed
this can cause problems with some applications: e.g. those using the
certificate fingerprint for blacklists.
1. Reject signatures with non zero unused bits.
If the BIT STRING containing the signature has non zero unused bits reject
the signature. All current signature algorithms require zero unused bits.
2. Check certificate algorithm consistency.
Check the AlgorithmIdentifier inside TBS matches the one in the
certificate signature. NB: this will result in signature failure
errors for some broken certificates.
3. Check DSA/ECDSA signatures use DER.
Reencode DSA/ECDSA signatures and compare with the original received
signature. Return an error if there is a mismatch.
This will reject various cases including garbage after signature
(thanks to Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS
program for discovering this case) and use of BER or invalid ASN.1 INTEGERs
(negative or with leading zeroes).
CVE-2014-8275
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 684400ce19)
PR #3090
Reported by: Franck Youssef <fry@open.ch>
If no new reason codes are obtained after checking a CRL exit with an
error to avoid repeatedly checking the same CRL.
This will only happen if verify errors such as invalid CRL scope are
overridden in a callback.
(cherry picked from commit 4b26645c1a)
Reencode certificates in X509_sign_ctx as well as X509_sign.
This was causing a problem in the x509 application when it modified an
existing certificate.
(cherry picked from commit c6d8adb8a4)
this means that some implementations will be used automatically, e.g. aesni,
we do this for cryptodev anyway.
Setup cpuid in ENGINE_load_builtin_engines() too as some ENGINEs use it.
