-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Reference: CERT-EU Security Advisory 2014-022
 
Title: SSL Vulnerability in iOS and OS X [1]
 
Version history:

24.02.2014 Initial publication

 
Summary
=======

Due to a flaw in authentication logic on iOS and OS X platforms, an attacker can bypass SSL/TLS verification routines upon the initial connection handshake. This enables an adversary to masquerade as coming from a trusted remote endpoint and perform full interception of encrypted traffic between the client and the destination server, as well as give them a capability to modify the data in flight (such as deliver exploits to take control of the system) [1,2].

Background
==========

The code doing a signature verification has been compromised by forcing a jump. This signature verification is checking the signature in a ServerKeyExchange message. This is used in DHE and ECDHE ciphersuites to communicate the ephemeral key for the connection. Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It's possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There's no proof that the server possesses the private key matching the public key in its certificate [3].

It affects anything that uses SecureTransport, which is most software on those platforms although not Chrome and Firefox, which both use NSS for SSL/TLS. However, that doesn't mean very much if, say, the software update systems on your machine might be using SecureTransport.

Because the certificate chain is correct and it's the link from the handshake to that chain which is broken, certificate pinning would not have stopped this. Also, this doesn't only affect sites using DHE or ECDHE ciphersuites - the attacker gets to choose the ciphersuite in this case and will choose the one that works for them.

Also, this doesn't affect TLS 1.2 because there's a different function for verifying the different ServerKeyExchange message in TLS 1.2. But, again, the attacker can choose any version that the client will accept. But if the client only enables TLS 1.2 then it appears that would workaround this issue. Likewise, if the client only enabled the plain, RSA ciphersuites then there's no ServerKeyExchange and that should also work around this issue. (Of the two, the former workaround is much more preferable.)

Versions Affected
=================

iOS 6.x <6.1.6
iOS 7.x <7.0.6
OS X 10.9.x
 
What can you do?
================

On iOS devices update to the latest version of iOS (6.1.6 or 7.0.6)

On OS X devices do not use Safari - use Chrome or Firefox and update to a patched version as soon, as Apple issues it. 
 

More information
================
[1] http://support.apple.com/kb/HT6147
[2] http://www.crowdstrike.com/blog/details-about-apple-ssl-vulnerability-and-ios-706-patch/index.html
[3] http://en.wikipedia.org/wiki/Tcl

 
Best regards,


CERT-EU Team (http://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: cert-eu@ec.europa.eu
PGP KeyID 0x46AC4383
FP: 9011 6BE9 D642 DD93 8348 DAFA 27A4 06CA 46AC 4383
Privacy Statement:
http://cert.europa.eu/cert/plainedition/en/cert_privacy.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJTC14HAAoJEPpzpNLI8SVodCoQALtZbSmpHEa42d0YQaFwzXOf
GYG/OWIyu5xUAxG5d4WHRxr1oSR06Btav5DslIsl3zBbC6cFCc2F4pagCiZTbf2H
iPO8WbNr/ARbopGwp1SDhqq+2ONUsI75dczajwiF4G1txR0jP0n4+35wDddtbMGC
Is9uhPN1FUjDpUb022bCS6rMLjfxwEy/PGhdTAC9mGVOxyNTDbIeuqTnZdj8ZmCN
tI7ydqOkPkAe+MicoZjdmO0DR+z4WZp7RPAFxqyCZSMB2Rga9wAP0l4CazCKj+ZS
Eq1No1RTZj05zBaSmwzrExQa6I0jhvnNk7cEntIdgxmv/Rt+2rclH4/++Q4XiLSc
ZIpF6ikizuW6VWslRkMDcnn1KIu2gLmB5EvKjQiZx/BOhxgtdGysLjCJN+WoYjY6
SVMtOF1zMB3YiuyZ69kiyW0OWKiY+As6QtUi01d9FSpnZSmom6Opxq9hYvZg0kdT
FPqWA9+UgvNHVgt1ccg4rt1FjiAsC9haj3qj7AqfOLb68l2c39PFqJ9ir1n0k+mw
OsAeeXS+FQzD3vzAIhotW8I8Rwxuq4bfM6F+yCbkFBhQ03HiFcchJ/lWxZL4pKDJ
WwclN0uEtHz/+KLbau/PSdXNYp5KOGDyPEyPErYSCBOogiCV1U8nB/FksifvZSNC
LGFkpDjDxRkUG96/AqHr
=m+Rs
-----END PGP SIGNATURE-----