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

[R C Delgado]

Thank you very much. It really helps.

On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> 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
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150710/fa29bfda/attachment.html>