An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it.
in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072)
'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.'
and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this:
RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE
|
V
VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set)
|
V
EVIL CERTIFICATE SIGNED BY PREVIOUS CERT
AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.
in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072)
'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.'
and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this: