Security Advisories

Trustwave Press Releases

« What Web Application Security Monitoring Can Learn From Casino Surveillance | Main | Auto-BAHN: Using Smart phones to create emergency, ad hoc networks »

07 August 2011


We've posted an updated workaround using OpenSSL that should resolve some of the limitations of the previous one:

First off, thanks to Adam Goodman for the extensive analysis and verification of the workaround. Seriously, fine work, Adam. Your additional perspective really helps.

As Sorcerer13 suggested, we originally targeted this workaround this for a fairly specific subset of use cases and geared our own validation around those cases. The leaf node validation workaround is admittedly too narrow in scope to proclaim this a general purpose workaround for _all_ use cases.

That said, not allowing intermediates _will_ address the vulnerability for some customers if they don't require support for intermediates. However, for some, a more extensive workaround which implements actual DER parsing and correct chain validation is probably necessary for some customers as well. I know of at least one application which has implemented this more or less with a 3rd party API. I should point out, that as far anybody knows the actual DER parsing on iOS is not where the vulnerability existed, so it may still be possible to leverage the Apple core API's to do what you are suggesting without OpenSSL. That said, it could be a dead end. Nobody but Apple knows for sure and they're staying pretty quiet.

Since the presentation at Defcon and publishing this followup blog post, we have been digging further into the security update to determine what exactly Apple has fixed. The fact is that it is incredibly frustrating that there is so little actual information out there on where the original flaw existed. We're trying to remedy this first and foremost. Hopefully more on this soon.

Adam, that behavior is expected.

"If not all the certificates needed to verify the leaf certificate are included in the trust management object, then SecTrustEvaluate searches for certificates in the keychain search list (see SecTrustSetKeychains) and in the system’s store of anchor certificates (see SecTrustSetAnchorCertificates)." - from the iOS Developer docs at

The locations of the intermediate certificates are located in the AIA extension of the leaf certificate - looks like that extension is not processed while manually verifying certificates. I'm fairly certain the above call was not developed for validating SSL certificates in that manner. The correct option would be to validate the certificate in the standard manner (i.e. transparently by the system, which would fetch intermediate certificates, perform SSL policy vaildation, perform revocation checks, etc) and then add the additional certificate as above.

Excellent work finding this vulnerability. After Moxie's initial discovery in IE made such a big splash almost a decade ago, I think many of us were content just to assume that this class of flaw was dead and buried (at least, in major OS implementations) - but clearly assumptions like these need to be challenged regularly.

Unfortunately, I don't think this workaround actually works. Or, more precisely, the extent to which it does work may only result from the fact that it removes intermediate CAs entirely from the validation chain - but this means that any certificate signed by any intermediate CA will fail to validate (unless that intermediate CA has been imported into the keychain or otherwise cached somehow).

I ran a few different tests:

First, I grabbed the leaf certificate currently used on, and attempted to use your 'isCertValid' code to validate it on an iOS device. It failed to validate. Then, following Apple's documentation, I instead passed the 'SecTrustCreateWithCertificates' function an array of two certificates - first, the leaf certificate, and second, Google's intermediate CA certificate ("Google Internet Authority"). This time, the certificate chain validated successfully.

Second, I created two certificate chains of my own, each with 3 certificates - a root CA, an intermediate CA, and a leaf Certificate. The first chain used an intermediate certificate with 'basicConstraints' set to 'CA:TRUE', the other used an intermediate CA with 'basicConstraints' set to 'CA:FALSE'.

I installed my test root certificate on two devices (by downloading it in Safari on each) - a vulnerable one running iOS 4.2.1, and a patched one running iOS 4.3.5. On each device, I first tried to validate the leaf certificates in isolation, as I had initially done with the Google leaf certificate. Both leaf certificates failed to validate on both devices.

I then added the appropriate intermediate certificates to each certificate chain, and tried the validation again. On the vulnerable device, both chains validated successfully. On the patched device, the chain with an intermediate CA with 'basicConstraints' set to 'CA:FALSE' failed to validate, and the other validated successfully. This is exactly the behavior I would expect to see with no workaround in place.

Assuming no mistakes on my part, I'm led to suspect that any successful workaround for this issue might require replacing - or augmenting - the actual chain-validation implementation. One possibility might be to cross-compile OpenSSL for iOS/ARM, and write a custom handler that grabs all the DER data for the certificates in the SSL peer's chain, and uses OpenSSL's validation rather than - or in addition to - iOS's. Unfortunately, that's rather more involved than just adding a few functions and custom handlers…

Otherwise, I guess the good news is that uptake for iOS updates is much faster than on just about any other mobile platform, though it's worth noting that Apple still has not released a patch for some older devices (e.g. my second-generation iPod Touch).

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)