Close ad

A few days ago, Apple released the hundredth iOS 7.0.6 update, about the release of which we informed you. Many may have been surprised that the update was also released for older iOS 6 (version 6.1.6) and Apple TV (version 6.0.2). This is a security patch, so Apple couldn't afford to update only a portion of its devices. What's more, this issue also affects OS X. According to Apple spokesperson Trudy Muller, an OS X update will be released as soon as possible.

Why is there so much hype surrounding this update? A flaw in the system's code allows server verification to be bypassed on secure transmission at the relational layer of the ISO/OSI reference model. Specifically, the fault is a bad SSL implementation in the part where server certificate verification takes place. Before I go into further explanation, I prefer to describe the basic concepts.

SSL (Secure Socket Layer) is a protocol used for secure communication. It achieves security by means of encryption and authentication of communicating parties. Authentication is the verification of the presented identity. In real life, for example, you say your name (identity) and show your ID so that the other person can verify it (authenticate). Authentication is then divided into verification, which is just an example with a national identity card, or identification, when the person in question can determine your identity without you presenting it to him in advance.

Now I would briefly get to the server certificate. In real life, your certificate could be, for example, an ID card. Everything is based on asymmetric cryptography, where each subject owns two keys - private and public. The whole beauty lies in the fact that the message can be encrypted with the public key and decrypted with the private key. This means that only the owner of the private key can decrypt the message. At the same time, there is no need to worry about transferring the secret key to both communicating parties. The certificate is then the subject's public key supplemented with its information and signed by the certification authority. In the Czech Republic, one of the certification authorities is, for example, Česká Pošta. Thanks to the certificate, the iPhone can verify that it is really communicating with the given server.

SSL uses asymmetric encryption when establishing a connection, the so-called SSL handshake. At this stage, your iPhone verifies that it is communicating with the given server, and at the same time, with the help of asymmetric encryption, a symmetric key is established, which will be used for all subsequent communication. Symmetric encryption is faster. As already written, the error already occurs during server verification. Let's take a look at the code that causes this system vulnerability.

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;
}

In the second condition if you can see two commands below goto fail;. And that is the stumbling block. This code then causes the second command to be executed at the stage when the certificate should be verified goto fail;. This causes the third condition to be skipped if and there will be no server verification at all.

The implications are that anyone with knowledge of this vulnerability can offer your iPhone a fake certificate. You or your iPhone, you'll think you're communicating encrypted, while there's an attacker between you and the server. Such an attack is called man-in-the-middle attack, which roughly translates into Czech as man-in-the-middle attack or man among. An attack using this particular flaw in OS X and iOS can only be executed if the attacker and the victim are on the same network. Therefore, it is better to avoid public Wi-Fi networks if you have not updated your iOS. Mac users should still be careful about which networks they connect to and what sites they visit on those networks.

It is beyond belief how such a fatal error could have made it into the final versions of OS X and iOS. It could have been inconsistent testing of poorly written code. This would mean that both the programmer and the testers would make mistakes. This may seem unlikely for Apple, and so speculations surface that this bug is actually a backdoor, the so-called. back door. It's not for nothing that they say that the best backdoors look like subtle mistakes. However, these are only unconfirmed theories, so we will assume that someone simply made a mistake.

If you are not sure if your system or browser is immune to this bug, visit the page gotofail.com. As you can see in the images below, Safari 7.0.1 in OS X Mavericks 10.9.1 contains a bug, while in Safari in iOS 7.0.6 everything is fine.

Sources: iMore, Reuters
.