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
