Fermer l'annonce
Des nouvelles

Détails de la mise à jour iOS 7.0.6 et SSL

Daniel Hruska
10

Il y a quelques jours, Apple a sorti le centième Mise à jour iOS 7.0.6, dont nous vous avons informé de la sortie. Beaucoup ont peut-être été surpris que la mise à jour ait également été publiée pour les anciens iOS 6 (version 6.1.6) et Apple TV (version 6.0.2). Il s'agit d'un correctif de sécurité, Apple ne pouvait donc pas se permettre de mettre à jour uniquement une partie de ses appareils. De plus, ce problème affecte également OS X. Selon la porte-parole d'Apple, Trudy Muller, une mise à jour d'OS X sera publiée dès que possible.

Pourquoi y a-t-il tant de battage médiatique autour de cette mise à jour ? Une faille dans le code du système permet de contourner la vérification du serveur lors d'une transmission sécurisée au niveau de la couche relationnelle du modèle de référence ISO/OSI. Plus précisément, la faute vient d'une mauvaise implémentation SSL dans la partie où a lieu la vérification du certificat du serveur. Avant d'entrer dans des explications plus approfondies, je préfère décrire les concepts de base.

SSL (Secure Socket Layer) est un protocole utilisé pour une communication sécurisée. Il assure la sécurité au moyen du cryptage et de l'authentification des parties communicantes. L'authentification est la vérification de l'identité présentée. Dans la vraie vie, par exemple, vous prononcez votre nom (identité) et montrez votre pièce d'identité afin que l'autre personne puisse la vérifier (s'authentifier). L'authentification se divise alors en vérification, qui n'est qu'un exemple avec une carte nationale d'identité, ou identification, lorsque la personne concernée peut déterminer votre identité sans que vous la lui présentiez au préalable.

J'aimerais maintenant aborder brièvement le certificat du serveur. Dans la vraie vie, votre certificat pourrait être, par exemple, une carte d'identité. Tout est basé sur une cryptographie asymétrique, où chaque sujet possède deux clés – privée et publique. Toute la beauté réside dans le fait que le message peut être chiffré avec la clé publique et déchiffré avec la clé privée. Cela signifie que seul le propriétaire de la clé privée peut déchiffrer le message. Dans le même temps, il n’y a pas lieu de s’inquiéter du transfert de la clé secrète aux deux parties communicantes. Le certificat est alors la clé publique du sujet complétée de ses informations et signée par l'autorité de certification. En République tchèque, l'une des autorités de certification est par exemple Česká Pošta. Grâce au certificat, l'iPhone peut vérifier qu'il communique réellement avec le serveur indiqué.

SSL utilise un cryptage asymétrique lors de l'établissement d'une connexion, ce qu'on appelle Prise de contact SSL. À ce stade, votre iPhone vérifie qu'il communique avec le serveur indiqué, et en même temps, grâce au cryptage asymétrique, une clé symétrique est établie, qui sera utilisée pour toutes les communications ultérieures. Le cryptage symétrique est plus rapide. Comme déjà écrit, l'erreur se produit déjà lors de la vérification du serveur. Jetons un coup d'œil au code à l'origine de cette vulnérabilité du système.

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

Dans la deuxième condition if vous pouvez voir deux commandes ci-dessous aller à l'échec ;. Et c’est là la pierre d’achoppement. Ce code provoque alors l'exécution de la deuxième commande au moment où le certificat doit être vérifié aller à l'échec ;. Cela entraîne l'omission de la troisième condition if et il n'y aura aucune vérification du serveur.

Les implications sont que toute personne connaissant cette vulnérabilité peut proposer à votre iPhone un faux certificat. Vous ou votre iPhone, vous penserez que vous communiquez de manière cryptée, alors qu'il y a un attaquant entre vous et le serveur. Une telle attaque s'appelle attaque d'homme au milieu, ce qui se traduit grossièrement en tchèque par attaque de l'homme du milieu ou homme parmi. Une attaque utilisant cette faille particulière sous OS X et iOS ne peut être exécutée que si l'attaquant et la victime se trouvent sur le même réseau. Il est donc préférable d’éviter les réseaux Wi-Fi publics si vous n’avez pas mis à jour votre iOS. Les utilisateurs de Mac doivent toujours faire attention aux réseaux auxquels ils se connectent et aux sites qu'ils visitent sur ces réseaux.

Il est incroyable de voir comment une erreur aussi fatale aurait pu se retrouver dans les versions finales d'OS X et d'iOS. Il aurait pu s’agir de tests incohérents sur un code mal écrit. Cela signifierait que le programmeur et les testeurs feraient des erreurs. Cela peut sembler peu probable pour Apple, et des spéculations font donc surface selon lesquelles ce bug serait en fait une porte dérobée, ce qu'on appelle. porte arrière. Ce n'est pas pour rien qu'on dit que les meilleures portes dérobées ressemblent à des erreurs subtiles. Cependant, ce ne sont que des théories non confirmées, nous supposerons donc que quelqu’un a simplement commis une erreur.

Si vous n'êtes pas sûr que votre système ou votre navigateur soit immunisé contre ce bug, visitez la page gotofail.com. Comme vous pouvez le voir dans les images ci-dessous, Safari 7.0.1 sous OS X Mavericks 10.9.1 contient un bug, tandis que dans Safari sous iOS 7.0.6, tout va bien.

Ressources: iMore, Reuters
La source
Discussion
Les sujets: , , , , , , , , ,

En rapport



Les plus lus články

.