Thursday, April 17, 2014

iOS clients not vulnerable to Heartbleed. What does the source say?

Apple's language in their assertion that they are not vulnerable to heartbleed on iOS are troubling as they specifically say (via ReCode), "IOS and OS X never incorporated the vulnerable software..."  However, not incorporating the vulnerable OpenSSL software is merely one way that their customers could have been made vulnerable.  What about the Apple SSL/TLS implementation?  Has anyone checked it?  Did they incorporate RFC 6520 for heartbeat support?  I couldn't find anything Google so figured I would share what I found.

Since the Apple SSL library code is open sourced, we can actually look at the code.  And based on my read of the code, Apple doesn’t even implement the heartbeat extension. doesn’t even define the heartbeat helloextension code 15 in the data structure:

/* Hello Extensions per RFC 3546 */
typedef enum
 SSL_HE_ServerName = 0,
 SSL_HE_MaxFragmentLength = 1,
 SSL_HE_ClientCertificateURL = 2,
 SSL_HE_TrustedCAKeys = 3,
 SSL_HE_TruncatedHMAC = 4,
 SSL_HE_StatusReguest = 5,

 /* ECDSA, RFC 4492 */
 SSL_HE_EllipticCurves  = 10,
 SSL_HE_EC_PointFormats = 11,

    /* TLS 1.2 */
    SSL_HE_SignatureAlgorithms = 13,

    /* RFC 5746 */
    SSL_HE_SecureRenegotation = 0xff01,

  * This one is suggested but not formally defined in
  * I.D.salowey-tls-ticket-07
 SSL_HE_SessionTicket = 35
} SSLHelloExtensionType;

Then in the implementation, they actually only support one extension, SSL_HE_SecureRenegotation. All others return an error code.

     switch (extType) {
            case SSL_HE_SecureRenegotation:
                    return errSSLProtocol;            /* Fail if we already processed one */
                got_secure_renegotiation = true;
                SSLProcessServerHelloExtension_SecureRenegotiation(ctx, extLen, p);
                 Do nothing for other extensions. Per RFC 5246, we should (MUST) error
                 if we received extensions we didnt specify in the Client Hello.
                 Client should also abort handshake if multiple extensions of the same
                 type are found
So, it appears from the library code that they would not be vulnerable to this bug at all.

No comments:

Post a Comment