[openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[Matt Caswell]

On 10/07/15 13:09, R C Delgado wrote:
> Hello,
> 
> With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.
> How deep does the certificate chain have to be?
> If I have 2 self-signed CA certificates, and a non-CA certificate is
> received for verification, will this hit the problem?
> 
> Also, is it a condition of the bug that both CA certificates have to
> have the same subject names and keys, as suggested in the file?


The conditions for triggering the bug are a little complicated, but I'll
do my best to explain it.

Under normal circumstances things work as follows:

We are provided with a certificate to verify from a remote peer. Lets
call the certificate we are trying to verify Leaf.
As well as Leaf that has been provided from the remote peer, they also
supply us with a set of untrusted certs.
Finally we also have a store of trusted certs.

OpenSSL will first attempt to build a certificate chain. The chain
building works as follows (much simplified):

1. Set Leaf as the top of the chain
2. Look for the issuer of the cert at the top of the chain from within
the untrusted set. If we find it add it to the top of the chain
3. Repeat (2) until we can't find any more certs from the untrusted set
4. Look for the issuer of the top of the chain from the set of trusted certs
5. Repeat (4) until we can't find any more certs from the trusted set

If we've found a valid chain with a trusted self signed cert at the top,
then we stop there. If not, then we continue to look to see if there is
an alternative chain that can be built. This works as follows:

Pop all the trusted certs off the top of the chain, then start popping
the untrusted certs off. Each time we pop an untrusted cert off start
the chain building again from step 4.

The bug occurs when during the initial chain building:
1) We have added at least one cert from the untrusted set
2) We have added at least one cert from the trusted store

For 1.0.2 there is the additional condition:
3) After doing (1) and (2) above we do not have a valid chain

Finally (for both 1.0.1 and 1.0.2)
4) After popping off at least one untrusted cert from the chain we can
build an alternative valid chain

Under the above conditions the end entity cert Leaf could "issue" a new
certificate even though it is not supposed to (I'll call that invalid
certificate "Bad").

So these certs would need to be present (at a minimum):

Chain 1:

Trusted Cert 1
|
Untrusted Cert 1
|
Leaf
|
Bad

Chain 2:

Trusted Cert 2
|
Leaf
|
Bad

There are other possible longer chains, but this is the minimum set. For
1.0.2, Chain 1 would have to be non-trusted, even though we have added a
trusted cert. This can occur if Trusted Cert 1 is not self signed and
its issuer is not in the trusted store. For 1.0.1 any chain will do.
Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers
of Leaf (i.e. they have the same subject names and public keys). Chain 2
must be trusted (so Trusted Cert 2 has to be a self-signed root).

Matt