iOS X.509
iOS X.509
At Recurity Labs, we conducted a project for the German Federal Office for Information Security (BSI), which (amongst others) also concerned the iOS platform. During the analysis, a severe vulnerability in the iOS X.509 implementation was identified.
When validating certificate chains, iOS fails to properly check the X.509v3 extensions of the certificates in the chain. In particular, the “Basic Constraints” section of the supplied certificates are not verified by iOS. In the Basic Constraints section, the issuer of a certificate can encode whether or not the issued certificate is a CA certificate, i.e. whether or not it may be used to sign other certificates. Not checking the CA bit of a certificate basically means that every end-entity certificate can be used to sign further certificates.
To provide an example: When a CA issues a certificate to a Web site, the CA will usually set the CA bit of this certificate to false. Assume, the attacker has such a certificate, issued by a trusted CA to attacker.com. The attacker can now use their private key to sign another certificate, which may contain arbitrary data. This could for instance be a certificate for bank.com or even worse, it could be a certificate containing multiple common names: *.*, *.*.*, etc. iOS fails to check whether the attacker’s certificate was actually allowed to sign subsequent certificates and considers the so created universal certificate as valid. The attacker could now use this certificate to intercept all SSL/TLS traffic originating from an iOS device. However, SSL/TLS is not the only use of X.509. Every application that makes use of the iOS crypto framework to validate chains of X.509 certificates is vulnerable.
The idea that Apple could have made a 8 year old mistake was suggested by Bernhard ‘bruhns’ Brehm (thanks man!).
The issue has been fixed in iOS 4.3.5.