Ceci démontre une fois de plus qu’une « petite » erreur de codage peut avoir des conséquences incalculables !

La preuve: en négligeant de vérifier sérieusement le code source de sa librairie SecureTransport, Apple a laissé une faille de sécurité très importante sous iOS, Mac OS X, et de nombreuses applications utilisant la même librairie.

Vendredi dernier, Apple a publié une mise à jour de son système iOS (et pour iOS 6), en admettant qu'il s'agissait de combler une faille critique dans la gestion des connexions chiffrées SSL/TLS.

Le bug se cacherait dans une librairie Apple, responsable de la vérification des signatures électroniques des certificats, au moment où s’établit la connexion SSL/TLS.

Le problème est apparu sur iOS 6.0 et a persisté sur les toutes dernières versions d'iOS, jusqu'à vendredi.

La faille existe aussi sous Mac OS X, et n'a pas encore été corrigée sur le système d'exploitation qui équipe les ordinateurs Apple.

L’origine de la faille :

Concrètement, une ligne de code (« goto fail ;»),  (voir :(1)) a été malencontreusement  dupliquée, ceci ayant pour conséquence  que le système valide n’importe quelle signature.

L’authenticité du certificat n’est donc jamais vérifiée, ce qui laisse la porte ouverte aux attaques par usurpation d’identité.

Lorsque l’utilisateur surfe sur une page sécurisée (email, services bancaires, etc.), un tiers pourrait s’insérer entre le terminal et le point d’accès Internet et se faire passer, pour le site en question (attaque dite « man in the middle »).

Il peut  ainsi capter les données, ou modifier avant de les renvoyer au vrai site.

Il est donc conseillé d’installer le patch le plus vite.

On mentionnera toutefois que pour exploiter cette faille, il faut pouvoir accéder au réseau qui connecte le terminal à l’Internet.

 S’il s’agit du propre réseau Wifi domestique et que celui-ci est correctement protégé (AES), le risque est faible.

Par contre, sage précaution, il faut éviter les hots spots publics, dans les cafés, les parcs ou les aéroports.

Attention : cette faille existe également pour les ordinateurs sous Mac OS X. Apple n’a pas encore publié de patch de sécurité pour ces systèmes, mais devrait le faire cette semaine.

Une simple négligence ? On peut s’interroger sur l’origine de ce bug.

Pour certains, il ne s’agit que d’une simple défaillance humaine, une erreur de codage.

Pour d’autres cela parait très suspect ! Cela pourrait être un acte de sabotage volontaire.

Certains y voient déjà la main de la NSA qui, on le sait maintenant, dispose de tout l’arsenal pour s’introduire dans les réseaux informatiques.

John Gruber, un programmeur spécialisé dans les systèmes Apple, estime que la NSA avait probablement connaissance de cette faille, et qu’elle l’exploitait.

 Il ne pense pas cependant qu’Apple soit complice dans cette affaire.

(1)           Pour les amateurs de codage : L’origine de la faille. Une erreur de codage « toute bête » qui peut avoir de graves conséquences ! Un petit exercice de programmation par un développeur d’Apple

Sur son blog personnel, Adam Langley, développeur chez Apple, explique que la faille est due à un bug dans l'écriture d'une librairie dont Apple avait rendu le code source public.

 On y trouve une série d'instructions conditionnées (if), visant à vérifier l'une après l'autre qu'aucune des conditions d'échec de la sécurisation de la communication n'est remplie.

En cas d'erreur, le code renvoie à la fonction de mise en échec (fail) si la condition est remplie. Une fois la fonction « fail» résolue, les autres conditions sont ensuite étudiées dans l'ordre prévu.

Le renvoi éventuel à la fonction d'échec est réalisé par la ligne « goto fail »que l'on retrouve à plusieurs reprises dans le code.

Mais à un endroit du code source, la ligne « goto fail; » était écrite deux fois de suite.

Or seule la première est interprétée comme la marche à suivre si la condition est remplie.

Le deuxième « goto fail » est exécuté systématiquement, avec pour effet de négliger toutes les autres vérifications de sécurité prévues.

De cette manière n’importe quelle personne qui  exploitait les problèmes de sécurité non vérifiés pouvait réussir son attaque.

La librairie SecureTransport qui contient ce code source ayant été mise à disposition des développeurs par Apple, ce sont tous les logiciels qui utilisent SecureTransport qui sont victimes du même problème de sécurité.

Adam Langley  estime que l'erreur aurait pu être évitée en utilisant les parenthèses { } pour toutes les instructions conditionnées.

Dans ce cas, le doublon aurait fait partie du bloc if, et n'aurait jamais été exécutée si la condition décrite n'était pas remplie.

Reconnaissant que la politique d'Apple d'examen du code est sans doute trop laxiste comme le montre cet incident, il lui parait indispensable que du code modifié soit validé par plusieurs  codeurs avant d'être déployé sur des produits aussi sensibles.