Adam Langley explained the reasons for the bug in iOS: an extra line of code broke all security

    Yesterday, Apple released the iOS 7.0.6 security update for iPhone 4 and later, iPod touch 5th generation and iPad 2+. At the same time, a similar patch 6.1.6 was released for the iPhone 3GS and iPod touch 4th generation.

    The update closes the vulnerability CVE-2014-1266, which allows an attacker from a "privileged position on the network" to intercept and modify packets in sessions protected by SSL / TLS . This is a MiTM attack with the substitution of traffic.

    In a concise explanation, Apple says that when establishing a secure connection via SSL / TLS, the system is not able to determine the authenticity of the connection. The problem was solved by “adding the missing stages of validation”.

    Although the concise description is not entirely clear what specific “steps” were missing, we can talk about the lack of full protection for the connections. One way or another, but the lack of the necessary authentication steps means that earlier on all Apple devices, third parties could probably install fake / modified OS updates on users' smartphones and tablets.

    Today, the famous cryptographer Adam Langley published an article analyzing the bug in iOS. He draws attention to the difference in the code of OS X 10.8.5 (Security-55179.13) and 10.9 (Security-55471), where the same bug is probably fixed.

    Actually, here he is.

    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 published Apple sources .

    Pay attention to two lines goto failin a row. The first of them correctly communicates with the operator if, and the second has nothing to do with the matter at all. As a result, program execution always ends at this stage, from the second goto fail. The value errcontains the correct value because the SHA1 update operation was successful and signature verification always gives the go-ahead.

    It's about verifying a signature in a ServerKeyExchange messagethat is used in the DHE and ECDHE ciphers to transmit a one-time connection key. The server says: "Here is a one-time key, and here is the signature from my certificate, so you know that the key is from me." In the case of Apple, if the connection between the one-time key and the certificate is broken, then the whole system is falling apart. Now nothing works at all: you can send the correct certificate to the client, but sign the handshake with an arbitrary secret key, or not sign it at all! There is no evidence that the server that sends the certificate generally has a secret key for this certificate.

    The vulnerability is probably present in all versions of iOS prior to 7.0.5 and in OS X up to 10.9.1 inclusive.

    Also popular now: