La faille Goto fail fait des émules
La découverte de la faille Goto fail au cœur d’OS X et d’iOS a poussé certaines sociétés à vérifier leurs codes. Bien leur en a pris, car la société Red Hat au cours de son audit, a trouvé une faille similaire dans la bibliothèque GnuTLS, qui est une implémentation libre des protocoles SSL et TLS.
Le mal est assez similaire : une erreur dans l’algorithme encore une fois avec une instruction Goto mal utilisée, qui fait qu’une personne malintentionnée peut émettre un certificat qui passera sans encombre toutes les procédures de vérification. Des correctifs sont d’ores et déjà disponibles pour les version 2.x/3.x de GnuTLS.
Les administrateurs vont avoir du boulot, car GnuTLS est utilisé dans de nombreuses distributions Linux à commencer par Red Hat Enterprise Linux, SUSE Linux Enterprise Desktop ainsi que dans de nombreux logiciels dont GNOME, Weechat, wireshark, Lynx et CUPS.
Les goto sont complètement interdit dans mon établissement en c, c++, java, ... Et je comprend vraiment pourquoi aujourd'hui
Remplace le goto par un appel à une fonction et tu n'as plus de goto dans ton code mais tu as toujours la faille...
Dois-je arrêter d'utiliser Goto dans mes programmes en Basic sur ma TI-82 Stats ? :P
C'est incroyable cette faille...
@Barbababar :
Évidemment ! C'est de la pure folie ! ^_^/s
"Beaucoup de prof d'informatique ont une sainte horreur de l'instruction goto. Ça ne va pas aller en s'arrangeant !"
Haha!! Ça c'est clair!!
Pour savoir si GnuTLS est installé sur les systèmes à base de yum/rpm : rpm - qa | grep -i gnutls
Je me souviens même de certains profs qui prétendaient que l'instruction GOTO n'existait pas en C, ça leur évitait d'avoir à nous démontrer par A+B les raisons de ne pas l'utiliser!
Sur Internet devinez ce que j'ai trouvé : des sources de Linux libres de droit !!!! Autrement dit n'importe quel pirate voit les failles de Linux et peux les exploiter !
(jvachez)
Dze Grand Master :incline:
Je suis étonné qu'on utilise encore cette instruction et de plus dans une telle librairie.
Y en a pas souvent des failles dans les systèmes UNIX mais quand y en a une elle se voit ! Bon beh l'honneur d'Apple est sauf alors (façon de parler évidemment). Des traces de GnuTLS dans Android peut-être ?
@joneskind :
C'est méchant mdrrrr
Outre l'horreur de l'utilisation de l'instruction goto, je note qu'un autre argument des pro-open source s'envole en fumée : celui qui dit que parce que le code est ouvert, il est souvent revu et donc plus fiable. L'aventure d'Apple et cet exemple nous montrent que cet argument ne tient pas.
@Darth Philou
En 6 ans de système UNIX, c'est la première faille majeure que je vois.
Mais forcément, c'est plus facile de se focaliser sur un bouton quand t'en as qu'un seul que quand t'en as 30 000 autour.
Inutile de le rappeler, aucun système n'est infaillible. Certains le sont plus que d'autres.
@Darth Philou
Mouais. Enfin y'a plein de failles exploitées dans les logiciels commerciaux (je pense au jailbreak des iPhone par exemple).
Et probablement plein de failles exploitées, mais non divulguées.
Le fermé ne protège pas forcément.
Ce que je vois, c'est qu'au moins avec l'open-source, elles ont plus facilement de chance d'être trouvées, et donc d'être plus facilement exploités, MAIS AUSSI plus rapidement et fréquemment fixées. Oui c'est à double tranchant, mais très rapidement bénéfique.
La sécurité basée par l'obscurité n'est payante (et encore assez rarement) qu'à très cours terme (http://fr.wikipedia.org/wiki/Sécurité_par_l'obscurité). Et ce n'est souvent pas ce qu'on veut.
@apple_julien
Je n'ai pas dit que le code fermé protégeait ; j'ai dit que le code ouvert n'a pas permis d'éviter cette faille pourtant "facile" a détecter : une simple lecture du code suffit.
@Darth Philou
"une simple lecture du code suffit"
Alala... Si c'était aussi simple... Tu penses bien que s'il suffisait d'écrire correctement un code pour qu'il soit sans faille, ça fait longtemps qu'on aurait réglé le problème...
Non, une simple lecture du code ne suffit pas. Le principe d'une faille c'est qu'une portion de code renvoie autre chose que ce qu'elle devrait renvoyer. Parfois le programme plante, mais parfois il se passe autre chose, comme un accès au système par exemple. Une bonne illustration c'est les mecs qui arrivent à accéder à certaines fonctions d'iOS en faisant une suite de manipulation sans le moindre sens. Ces manipulations n'ont bien évidemment pas été codées.
La faille GoTo c'est la même chose. Son comportement n'était pas prévisible. Par contre une fois qu'elle est connue, il est très facile de la reproduire. C'est d'ailleurs ce qu'il s'est produit ici.
C'est une des limites de la théorie du libre d'ailleurs que de considérer que le code libre est lu par beaucoup de monde et donc vérifié. Le problème c'est pas de le lire, le problème c'est de le mettre à l'épreuve.
D'accord. Mais pour un échec du modèle, combien de réussites ?
Un code fermé commercial sera souvent écrit, et lu, par un seul développeur (voir deux en extrême programming), et vaguement testé par des tests unitaires. Bon. Y'a des chances qu'un nombre non négligeable de bugs / failles y reste.
Alors que le libre, il y a beaucoup plus de probabilités que le code soit lu et testé par plus de monde.
Et en fait, en pratique, souvent ça marche bien. Pour une faille non fixée qui fait du bruit, plein d'autres sont fixés avant d'être intégrés dans un produit releasé, voir plus tard, mais rapidement, par des white hat.
Bizarrement, j'ai comme l'impression qu'on ne va pas parler autant de ce cas-ci dans les médias du monde entier. ;-)
C'est bien évidant ça ne concerne pas Apple ........ Juste a voir quand une schtouille se retrouve sous Android pas un seul mot dans les média qui exploite a fond la carte Apple pour basher ..... C'est branché le Apple bashing
@BeePotato :
En même temps, tu en connais beaucoup des M. et Mme Tout-le-monde qui ont une machine Linux susceptible d'avoir cette faille ?
On ne peut pas comparer un téléphone grand public qui se vend à des millions d'exemplaires et un système certes très utilisé aussi, mais uniquement par des professionnels et des geeks. On en parlera donc dans la presse spécialisée, mais pas dans 20minutes ni dans Le Monde.
Et au fait, ce n'est pas l'instruction goto elle-même qui est responsable de toutes les misères du monde informatique, hein. C'est juste la mauvaise utilisation qui en est faite ici.
Il est possible d'arriver au même genre de faille par d'autres moyens, sans utiliser goto.
Je n'ai jamais été d'accord avec l'approche extrémiste du « jamais de goto ».
Allons bon. Tous ceux qui travaillent dans l'aéro (et plus généralement dans les logiciels à haute sécurité : transport, spatial, nucléaire, médical, automobile - ah non pas l'automobile me souffle-t-on dans l'oreillette), tous les profs ou presque, sont donc de dangereux extrémistes...
Surement extrémistes, oui. L'argument d'autorité n'est pas un argument en soi (http://fr.wikipedia.org/wiki/Argument_d%27autorité). Le mieux, c'est encore d'avoir une approche non doctrinaire de ça, et de savoir prendre un peu de recul et des pincettes.
Ahhhh de mieux en mieux. Les milliers d'experts internationaux qui se sont penchés sur la question et ont défini des règles et des normes sur le sujet ont une approche doctrinaire. Et ils manquent de recul. Avec un smiley, ça aurait pu être drôle. Bon aller, assez rigolé, faut que j'aille me coucher, je bosse demain.
Vous avez les sources de ces affirmations ?
Un truc qui dirait quelque chose du genre "l'instruction goto est intrinsèquement dangereuse pour la sécurité / stabilité des applications, donc même dans les simples cas de gestion d'erreur, et forcément plus qu'un simple return"…
Si vous aimez les arguments d'autorité, alors j'aurais tendance à dire que y'a pas que des guignols qui bossent sur ces sources là (en fait y'a même très peu de guignols - y'a même beaucoup de monde dont la sécu est leur "dada"). Et des "goto" utilisé pour la gestion d'erreur, c'est assez courant.
Les "milliers d'experts internationaux qui se sont penchés sur la question" ne sont pas doctrinaires puisque l'instruction "goto" existe encore partout. Elle doit donc avoir son intérêt, non?
Ce qui est doctrinaire -donc stupide- c'est d'interdire purement et simplement le goto.
Dormez bien, prenez soin de ne pas vous étrangler de rire.
1. Des goto, t'en fais tout le temps. Mais ils portent d'autres noms: for, while, exit etc...
2. Les profs on leur a dit que goto c'est mal, alors ils enseignent que goto c'est mal.
3. Ici il s'agit clairement de s'assurer que le nettoyage mémoire est fait correctement après une exception et éviter un memory leak ou pire. Tu fais comment toi? Tu nettoies pas? Tu ajoutes plein de conditions pour éviter d'exécuter le code après en forçant la sortie de boucle? C'est bien entendu possible, mais je doute que ce soit meilleur comme solution.
@ jb07 : « Allons bon. Tous ceux qui travaillent dans l'aéro (et plus généralement dans les logiciels à haute sécurité : transport, spatial, nucléaire, médical, automobile - ah non pas l'automobile me souffle-t-on dans l'oreillette), tous les profs ou presque, sont donc de dangereux extrémistes... »
Je clarifie ce que je voulais dire : les développeurs qui s’imposent à eux-mêmes cette règle ne sont pas visés par ce que je disais — ils se sont créé, comme tout le monde, des règles de programmation qu’ils suivent tant bien que mal. J’espère justu pour eux qu’ils se sont imposé ça après avoir acquis une bonne connaissance de l’utilité et des dangers du goto, et non juste parce qu’un de leurs enseignants ou collègues leur a dit que c’était le mal incarné.
Et j’espère aussi qu’ils sont conscients qu’ils peuvent arriver au même type de problème par d’autres moyens (ben oui, le goto c’est le mal, mais les langages qui permettent de générer des exceptions, c’est le bien — sauf que le genre d’erreur qu’on a vu dans le cas d’Apple est tout à fait faisable avec une génération d’exception (ou même avec un bête return)).
En revanche, ceux que je qualifie d’extrémistes sont ceux, développeurs ou enseignants, qui expliquent à tout le monde qu’il ne faut jamais utiliser de goto. C’est évidemment plus grave dans le cas des enseignants, qui sont censés expliquer les choses et non se contenter de répéter de telles affirmations catégoriques sans les justifier à fond.
La bonne approche est de présenter les risques liés à l’usage de goto, mais aussi son interêt et l’usage raisonné qu’on peut en faire (c’est ce que je fais quand j’enseigne et que je tombe sur une occasion de parler de goto). Et ces deux failles serviront à l’avenir de bon support pour cette explication.
Complètement d'accord avec @BeePotato
Ce n’est pas parce qu’il y a des profs limites tyranniques, vaguement bas de plafonds, qui enseignent certains "commandements" sur un mode bourrage de crâne, qu'il ne faut pas s'arrêter 5 min et se poser quelques questions.
À vrais dire, goto est vraiment problématique si ça doit aboutir à de la programmation "spaghettis" comme on pouvais le voir dans le BASIC. Là effectivement, la lecture du code devient presque impossible, et ne pas faire de bug aussi.
Néanmoins, utilisé avec (beaucoup) de parcimonie, dans des cas de gestion d'erreur, comme c'est souvent le cas (et c’est le cas dans ces deux cas), ne pose en soit pas de problème.
Je veux dire par là que le problème ici n’est pas intrinsèquement lié à l'instruction goto, mais à des erreurs humaines, non exacerbées par l’utilisation de cette instruction. Ils auraient utilisé un return au mauvais endroit ou un mauvais test dans une condition, le résultat n'aurait pas forcément été moins nocif.
Prenez du recul ;)
@apple_julien
Je ne comprends absolument rien de ce que vous racontez mais je trouve votre discours apaisant. Continuez je vous prie !
J'aimerai savoir le pourcentage de bugs et donc de failles qui sont uniquement du a un goto...
Contrairement a ce que disent les profs, le goto a certain usage. Mais c'est comme tous les outils, si c'est mal utiisé ca pête. C'est comme un return au mauvais endroit... Ou l'utilisation d'une variable non initialisée... Les profs c'est gentil, mais ils font de la théorie, la pratique c'est autre chose.
Tout ce que je vois dans le code c'est une erreur de logique, pas un probleme du a un goto...
C'est comme la faille sur OS X avec le goto fail; Le vrai probleme c'était plutot le non usage d'accolade dans le if plus que le goto en tant que tel.
J'aimerai connaitre le nombre de bugs dûs au fait de pas mettre d'accolade pour un if quand il y a une seule instruction.
@ Stardustxxx : « Les profs c'est gentil, mais ils font de la théorie, la pratique c'est autre chose. »
Euh… rappelons tout de même que dans l’enseignement supérieur en France, la plupart des enseignants en informatique sont des enseignants-chercheurs.
En dehors de leur service d’enseignement, ils se consacrent à leurs activités de recherche qui leur offrent, dans la plupart des cas, beaucoup d’opportunité de se confronter à la pratique du développement (il y a des exceptions, bien sûr, vu le large éventail de domaines de recherche en informatique).
Complètement d'accord avec apple_julien, BeePotato et Stardustxxx
Comme je suis vieux (donc naufragé comme dirait Moonwalker...) j'ai pratiqué le Fortran IV. Il n'y avait pas grand-chose d'autre à l'époque, même pas le C, pour le calcul scientifique et la phobie des profs d'info vis-à-vis des "GO TO" vient sans doute de là. A juste titre il faut bien le dire. Les programmes étaient bourrés de GO TO dans tous les coins, tout simplement parce que le if-then-else n'existait pas. Le pompon revant au "GO TO calculé" du genre GO TO (10,20,30), x. Tout ce cirque rendait les programmes totalement non structurés et difficilement lisibles.
C'est fini et c'est très bien. Mais ceci dit, il faut bien reconnaître que un bon vieux "GO TO" permet de temps en temps de bien simplifier les choses, et je ne vois pas ce qu'il y a là de scandaleux. L'intégrisme, c'est pas trop mon truc.
Et pour finir, dans le cas du "GO TO fail" qui nous occupe, le problème -comme déjà dit- ne vient absolument pas de l'usage du "GO TO" mais tout simplement d'une énorme bourde dans la programmation.
De plus, les programmeurs évitent les goto si ils le peuvent. Mais dans certains cas, au lieu d'avoir une cascade de if/else pour gérer toutes les erreurs, un simple goto peut nettement simplifier le code et le rendre plus lisible et plus comprehensif, plus facile a comprendre et donc plus facile a évaluer. Donc a priori moins prone aux bugs.
Combien de bug a-t-on éviter avec un bon usage du goto ?
Dans un language sans exception, comme le C, le goto est indispensable dans certains cas.
On peut aussi faire un audit du code de Linux et compter le nombre de goto présent pour rigoler ;)
@apple_julien :
+1
Ça fait du bien de lire des commentaires de gens qui savent de quoi ils parlent.
@apple_julien
Voilà enfin une intervention éclairée.
Si les profs prohibent l'usage du goto, ce n'est pas par tyrannie ou par dogmatisme bas du plafond (en tout cas pas tous), mais parce qu'il est extrêmement facile d'abuser du goto (tu l'as souligné toi-même). De plus, le goto étant la forme la plus universelle de branchement, il pourrait détourner un étudiant d'utiliser d'autre forme de branchement.
D'ailleurs, je me demande si aujourd'hui, les profs insistent encore dessus. De mon temps, c'était nécessaire, car les profs étaient confrontés à des classes de boutonneux qui avaient déjà acquis la mauvaise pratique du goto avec le QBasic du PC de papa ou la programmation de la calculatrice TI. Je ne sais pas si les jeunes autodidactes d'aujourd'hui n'évitent pas spontanément cet écueil, vu que l'usage du goto s'est beaucoup estompé dans la culture de la programmation depuis 20 ans : les livres d'apprentissage, les cours sur le net, les aides des langages ne l'abordent qu'en insistant sur son caractère dangereux.
Mais pour le reste, je suis d'accord.
Hmmm. Bon, je ne peux être que d'accord sur le fait que oui, évidemment, les profs sont tous dans une logique bienveillante quand ils enseignent le goto=mal.
Mais je pense que dans cette catégorie de profs, on doit pouvoir distinguer au moins deux types :
- Ceux qui pensent vraiment que c'est mal, sans vraiment s'être posé de questions sur le pourquoi de cette affirmation, et sur l'éventualité d'être moins "manichéen". Je ne peux que les désigner comme vaguement bas de plafonds, et leur conseiller peut-être de faire un autre métier, car il me semble que c'est assez problématique quand on est prof et qu'on apprend, entre autres, aux gens à réfléchir et à se poser des questions…
- Ceux qui ont parfaitement pesé le pour et le contre, mais préfère simplifier la question en répétant le mantra "goto=mal" pour éviter tout dérapage de la part de ses élèves. Et là, j'ai envie de dire : l'enfer est pavé de bonnes intentions. Soyez moins condescendant, et faites un peu confiance aux capacités intellectuelles de vos élèves à comprendre les choses.
Après bien sûr, je ne pense pas que ce genre de prof soit une majorité, et bon nombre (dont ceux que j'ai eus) ont une vraie approche pédagogique, et explique clairement le pour et le contre, avec une grande rigueur. Ils font leur métier de prof, en quelque sorte :)
Quand je vois les réactions ici et sur le net en général sur ce goto, je me dis que l'endoctrinement sur ce sujet-là n'est pas fini.
D'accord avec l'ensemble de ce commentaire (et concernant les enseignants qui donnent dans le « goto == outil du diable », j'ajouterai une précision : parmi les enseignants-chercheurs, certains sont bien plus chercheurs qu'enseignants et ça se voit — c'est un des défauts de cette approche).
Le GOTO n'a rien de démoniaque, il doit simplement être réservé aux bons programmeurs ! d'ailleurs il y a un excellent papier datant de 1974 (!), "Structured Programming with go to Statements", du Pape de la programmation, Donald Knuth lui-même (le célèbre auteur de la collection The Art of Computer Programming), qui défend l'usage raisonné du GOTO. Comme quoi...
@Stardustxxx :
'Dans un language sans exception, comme le C, le goto est indispensable dans certains cas.'
Indispensable dans certains cas ???
Je veux bien un exemple.
Je suis développeur depuis... très longtemps. En Common Lisp, puis en C, VB 6, C++, Objective C, Javacript et php. Et bien je n'ai jamais utilisé de GOTO. Peut-être parce que j'ai eu des cours de programmation structurée comme on disait fin des années 80, inspirés du Pascal ?
Si vous voulez des exemples de bonnes pratiques de traitement d'erreurs en C, je vous invite à lire les Inside Macintosh 2nde édition de l'ère Mac OS 7 / 9.
Et dans UNIX (pas Linux), combien de GOTO ?
Autre chose : GOTO ou pas, il faudrait rappeler à certains donneurs d'ordres et patrons l'importance des tests (unitaires) et autres "recettes".
Mais parfois il faut se battre pour produire de la qualité. j'ai en effet été médusé récemment par le chef de projet d'une SSII sur un projet de statistiques pour la RATP. « Qualité ? Faut faire vite. Et puis s''il faut allouer 1 Go de mémoire au processus http, on le fait. C'est plus simple de tout charger un mémoire. » Des fichiers à importer de 10 millions de lignes... Je suis parti avant la fin, et je n'ai mis aucun (c) dans le code...
@marc_os :
'Et bien je n'ai jamais utilisé de GOTO'
Oups, autant pour moi : En VB 6, le traitement d'erreurs passait en général par des GOTO.
Dernière remarque sur les parenthèse et les "if". D'accord avec la remarque qu'il vaut mieux toujours en mettre. Ça évite les erreurs dues à des modifications de code.
Corollaire : « Pas de if sans else, ou bien un commentaire disant pourquoi il n'y a pas de else. Le développeur qui reprendra le code appréciera; et même l'auteur du code... un an plus tard.
Loin de moi l'idée de demander un cours de programmation, j'ai trop mangé d'assembleur et de c et compagnie, jusqu'à ne plus rien y comprendre, je me limite à l'html, css :-) :
Pourriez-vous en vulgarisant, expliquer ce qui se passe avec l'instruction goto? Elle envoie à un mauvais endroit et crée une faille?
Merci de vos réponse.
La commande "goto" permet simplement de sauter d'un endroit du code à un autre (vers un label) de manière inconditionnelle. Si tu as fait de l'assembleur, ça correspond au "jmp" du x86, ou au "b" du ppc.
C'est une instruction extrêmement basique, bête comme tout, mais en même temps très puissante, puisqu'elle permet de court-circuiter (d’enjamber) tout un pan d’instructions. C'est ce qui se passe avec la faille d'Apple : à cause d’un goto qui se trouve au mauvais endroit en plein le flux d'exécution du programme, boom, ça saute à la fin de la fonction, cours circuitant par la même occasion un ensemble de vérifications qui font la raison d'être de la fonction.
Alors on peut faire plusieurs constats, et c'est l'essence du débat :
- C'est une commande dangereuse : la preuve, ici avec cette faille. Le contre argument serait de dire qu'un return n'est pas moins dangereux : ça permet aussi de court-circuiter des pans de code (d’ailleurs un return est souvent implémenté avec un saut vers l'épilogue de la fonction - restauration de registres, retour vers l'appelant, etc.). Le tout est de savoir ce qu’on fait, et de faire attention à ce qu'on fait.
- C'est de la programmation spaghettis. Alors là, oui et non. Effectivement si on s'en sert pour fabriquer des boucles ou gérer des actions de tests, ça devient souvent illisible. Mais c'est un problème strictement humain, à savoir l'incapacité qu’on à de se représenter mentalement ce que fait la fonction quand le contrôle du flux d'exécution perd une certaine linéarité (le processeur s'en sort en fait très bien, lui). Donc ce qu'on convient souvent, c'est de l'utiliser avec grande prudence, dans des cas extrêmement restreints (typiquement la gestion d'erreur), pour que la lisibilité humaine reste suffisamment bonne pour comprendre ce qui se passe au premier coup d’oeil.
Super clair, merci beaucoup :-)
@ apple_julien : « pour que la lisibilité humaine reste suffisamment bonne pour comprendre ce qui se passe au premier coup d’oeil »
Tout en n'oubliant pas qu'une apparente lisibilité est parfois trompeuse.
Dans le cas qui est présenté ici, le gars qui a écrit un « goto cleanup » avant un « goto fail » a dû trouver que ça rendait le tout plus lisible. :-)
Complément d'explication pour EBLIS qui posait la question : manque de pot pour ce programmeur, c'est comme ça qu'il a créé une faille. Après le « goto cleanup » (manifestement destiné à exécuter du code de nettoyage de ce qui avait été fait plus haut dans la fonction), l'exécution ne revient pas à cet endroit du code pour exécuter le « goto fail » (saut vers le code qui permettrait à la fonction de signaler l'échec d'un des tests). Du coup, même si la condition testée dans le « if » est fausse, ça n'est pas signalé.
Une erreur qu'on peut justement rencontrer chez certains programmeurs n'ayant pas été suffisamment bien formés au goto, et qui ont tendande à confondre ça avec un appel de fonction.
Oui, précisions utile effectivement. Merci :)