Apple vient de corriger son noyau iOS qui était affecté par une erreur de programmation (CVE-2014-1266). Cette faille concernait la gestion des communications chiffrées SSL qui devenait susceptibles d’être interceptées et modifiées par un attaquant situé sur le même réseau que celui utilisé par la machine-victime. Le problème concerne les liaisons établies avec le navigateur Safari. Chrome et Firefox ne sont pas concernés et peuvent donc être employés en toute tranquillité. La vulnérabilité serait postérieure à octobre 2013, dixit Stefan Esser.
La faille a fait l’effet d’une bombe dans les communautés de la sécurité et de la programmation. Non pas en raison de l’existence même de cette faille (il en est souvent d’encore plus critiques) mais de par sa nature. Matthieu Suiche l’explique très clairement : le bug est provoqué par une double instruction « Goto », ce qui crée, avec la seconde occurrence, un branchement inconditionnel dans une procédure pourtant censée vérifier un bon fonctionnement. Parvenu à ce point, le programme oublie simplement de continuer sa vérification. La bévue est d’ailleurs tellement énorme que le chercheur Français se demande s’il s’agit bien d’une erreur humaine. La majorité des compilateurs tirent un signal d’alarme s’ils rencontrent un tel branchement inconditionnel à moins que les options de compilation correctes n’aient pas été validées explique en substance Suiche. Or, dans une entreprise de l’importance et du sérieux d’Apple, on peut douter que de telles bonnes pratiques aient pu être négligées à ce point. Surtout dans le contexte actuel de la crise Prism.
Pour Steve Bellovin, voir la main de la NSA derrière le Goto Fail Bug frise peut-être la paranoïa ou l’amour du roman noir. Ce n’est là qu’un gros bug, la preuve d’une certaine légèreté de la part d’Apple en matière de bonnes pratiques de programmation et de contrôle-qualité du code. Bellovin, avare de billets de blogs durant ces quatre dernières années, a pourtant pondu deux articles sur le sujet. L’un technique, l’autre spéculativo-politico-stratégique. Il y a tellement peu d’intelligence derrière cette faille qu’il serait vain d’imaginer celle (d’intelligence) d’un service d’Etat, explique-t-il en substance. Si la majorité des arguments de ce Grand Maître de la Sécurité Informatique est frappée au coin du bon sens, l’argument principal demeure cependant un peu faible. L’argument du « trop gros pour être crédible » ( this is too visible and too clumsy) est précisément un principe élevé à la hauteur d’une religion chez les auteurs de malwares et les spécialistes des escroqueries en tous genres. Et puis, toute « visible » et toute « clumsy » qu’est cette faille Goto, elle a su survivre à l’insu de tous durant une période relativement longue. On a connu des cousins de Stuxnet bien moins vivaces.
Toutes aussi claires (et en Français) les explications de MM Nicolas Kerschenbaum, Miguel Enes et Fabien Jobin du Cert Lexsi, avec un superbe organigramme en prime. Ajoutons que Stephan Esser propose un correctif non officiel pour OSX.
Côté programmeurs, rarement une telle erreur n’aura soulevé autant de commentaires et ressuscité cette vieille querelle à propos de l’usage immodéré de l’instruction Goto. Laquelle fait ressurgir le spectre des codes spaghetti des branchements sauvages en Basic. Mais, dans ce cas précis, l’usage du Goto et les erreurs qu’il provoque n’ont rien à voir avec les principes de la programmation structurée. Return.
