Yesterday, Apple pushed iOS 7.0.6/6.1.6 as a security update for SSL/TLS but gave no details. We learned that HTTPS hasn’t protected users’ credentials and privacy for around a year.  Don’t use your iOS device if it’s not updated to iOS 7.0.6/6.1.6. People (with no special talent, just basic knowledge about sniffing) can grab any of your passwords without you noticing now that they know there is a security vulnerability in iOS versions prior to 7.0.6/6.1.6.

If you’re device is jailbroken, you might think that its not worth it to restore firmware, update it, then restore from backup but trust me if you don’t update and someone sniffs your password(s) or eBanking sensitive data you’ll wish you had taken those 15 minutes to make sure your device is running iOS 7.0.6/6.1.6.

For those of you who are code savvy and are interested to see what this patch fixed, have a look below:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
	OSStatus        err;
	...

	if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
		goto fail;
	if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
		goto fail;
		goto fail;
	if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
		goto fail;
	...

fail:
	SSLFreeBuffer(&signedHashes);
	SSLFreeBuffer(&hashCtx);
	return err;
}

(Quoted from Apple’s published source code.)

Note the two goto fail lines in a row. The first one is correctly bound to the if statement but the second, despite the indentation, isn’t conditional at all. The code will always jump to the end from that second goto, err will contain a successful value because the SHA1 update operation was successful and so the signature verification will never fail.

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. The server is saying “here’s the ephemeral key and here’s a signature, from my certificate, so you know that it’s from me”. 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.

Since this is in SecureTransport, it affects iOS from some point prior to 7.0.6 (It was confirmed on 7.0.4) and also OS X (confirmed on 10.9.1). 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.

For a more complete read on this issue press here