Discussion :

[Arsene Newman]

GnuTLS : un GoTo responsable d'une faille critique
La faille existerait depuis 2005, au vu de tout le monde

Edsger Dijkstra, informaticien de renom, nous avait déjà prévenu en 1968 que les sauts inconditionnels de type GoTo pouvaient s'avérer dangereux ; il avait même publié un article sur le sujet, intitulé GoTo Statement Considered Harmful.

46 ans plus tard, la chasse aux bugs et aux failles informatiques le prouve encore. En effet GnuTLS l'une des bibliothèques les plus populaires pour la gestion des certificats électroniques et l'implémentation des protocoles SSL & TLS sous Linux, serait affectée par une faille majeure due à un mauvais GoTo. Vu la popularité de la bibliothèque, on estime que des centaines d'outils pourraient être affectés à leur tour. C'est le cas par exemple de l'utilitaire apt-get utilisé sous Ubuntu et Debian ainsi que le client http en ligne de commande lib-curl dans sa version 3.

Dénommée CVE-2014-0092, la faille a été découverte par Nikos Mavrogiannopoulos, membre de l'équipe des technologies de sécurité de RedHat, lors d'un audit de GnuTLS. Elle existerait depuis 2005.

La faille serait due à une erreur de branchement GoTo (goto cleanup au lieu d'un goto fail) dans une section du fichier verify.c, responsable de la vérification de l'authenticité des certificats x509, ce qui aurait pour conséquence une terminaison inhabituelle du code de vérification et une détection erronée de l'authenticité d'un certificat électronique. Selon RedHat, un attaquant pourrait profiter de la faille pour créer un certificat « qui serait accepté par GnuTLS comme valide pour un site choisi par l'attaquant ».

Tout cela explique l'empressement de RedHat. Elle recommande le passage à la version 3.2.12 ou le fix des versions 2.12.x, grâce à un patch publié dans la foulée.

Enfin cette faille vient nous rappeler celle découverte sous les systèmes d'exploitation Apple, à savoir le fameux goto fail affectant les implémentations des protocoles SSL et TLS [lire l'article de la rédaction], même si pour beaucoup d'experts le goto cleanup de Linux serait bien pire et plus critique que le goto fail d'Apple.

Source : annonce sur le site de GnuTLS

Et vous ?

Qu’en pensez-vous ?

[xurei]

Les mises à jours sont déjà sur Synaptic (pour les Ubuntuiens).

N'empêche, c'est pas rassurant ce genre de conneries. Je n'arrive pas à croire que personne dans l'équipe de dev n'ai fini par voir cette erreur...

[Naoki-kun]

Tu sais, les lignes de codes, elles se comptent par millions...les gens qui analysent de fond en comble le code, sont beaucoup moins nombreux. Aussi, il n'est pas rare de passer à côté d'une erreur, aussi bête soit-elle. L'erreur est humaine, mais ce que l'on peut encore une fois mettre en avant pour un OS open-source, c'est que les failles sont rapidement corrigées, c'est la l'objectif d'une telle philosophie du libre.

[DrHelmut]

Naoki-kun, il y a plus de 10 ans je n'aurais pas rebondit, mais de nos jours, même des millions de lignes de code peuvent (et doivent surtout) être analysées au fur et à mesure.

Avec des analyseurs de code il est relativement facile de déterminer un goto inexistant ou autres bugs potentiels (jamais essayé mais vu la puissance d'outils comme sonar/findbugs et co, c'est forcément possible à moindre coût !)

Donc, pas vraiment d'excuse pour ce gros bug bien sale, c'est juste qu'il n'y a pas clairement pas eu la qualité attendue autour du dev (manque de test et d’analyse) => au bûcher !

[xurei]

D'accord avec DrHelmut. Je suis parfaitement conscient qu'il est extrêmement difficile de coder quelque chose de parfaitement bug-free.

Sauf que là, on parle d'un point critique de l'algo : la vérification du certificat. C'est LE bout de code le plus important dans une bibliothèque de ce type. Le bug serait là depuis 9 ans, c'est énormément long pour du code critique.

[jlliagre]

Avec des analyseurs de code il est relativement facile de déterminer un goto inexistant ou autres bugs potentiels (jamais essayé mais vu la puissance d'outils comme sonar/findbugs et co, c'est forcément possible à moindre coût !)

Il ne s'agit pas d'un goto vers un label inexistant, que tout compilateur aurait détecté de toute façon, mais d'un goto vers le mauvais label. Je ne vois pas comment un analyseur de code automatique pourrait détecter ce style d'erreur. Le code est "correct", c'est l'algorithme qui est faux.

[jlliagre]

ce que l'on peut encore une fois mettre en avant pour un OS open-source, c'est que les failles sont rapidement corrigées

En effet, il n'a fallu que 9 ans

[Njibhu_]

"dans la bibliothèque très utilisée sous Linux"
Sources ?

J'ai fait un repoquery pour savoir quels paquets utilisais gnutls dans tous les dépots de Fedora... sa représentais une 15ène de paquets.
Le seul qui m'a marqué c'était Xen mais d'après ce que j'ai vu il n'utilise pas la partie concernée par la faille de gnutls; les autres ne me disais vraiment pas grand chose (et pourtant je passe beaucoup de temps dans les dépots vu que je maintiens certains packages).

Certes le temps de détection peux être choquant mais pour une bibliothèque quasie inutilisée je trouve que l'on fait beaucoup de remous pour pas grand chose.
(A l'exception certes d'apt-get... mais il ne faut pas oublier qu'une grosse partie des utilisateurs de linux n'en restent pas concernés).

[TiranusKBX]

c'est pour ça que de ma boîte il y a une personne pour générer tous les bugs possibles ^^
même si il peut en rester ça devient improbable une telle faille

[Arsene Newman]

"dans la bibliothèque très utilisée sous Linux"
Sources ?

J'ai fait un repoquery pour savoir quels paquets utilisais gnutls dans tous les dépots de Fedora... sa représentais une 15ène de paquets.
Le seul qui m'a marqué c'était Xen mais d'après ce que j'ai vu il n'utilise pas la partie concernée par la faille de gnutls; les autres ne me disais vraiment pas grand chose (et pourtant je passe beaucoup de temps dans les dépots vu que je maintiens certains packages).

Regardes ce lien, à titre d'exemple en ce qui concerne Debian !

http://www.reddit.com/r/linux/commen...end_on_gnutls/

[abriotde]

L'analyseur de bug ne peut rien face a ça. C'est un retour qui est redirigé au mauvais endroit. Si c'était la fonctionnalité normal, cela ne poserait pas de problème. Un analyseur de bug peut trouver les bug qui sont des fautes logique. Il ne peut pas savoir ce que le programmeur voulait. pour détecter un bug, la revue de code est très efficace, mais plus un bug est gros, moins on le voit. Des bugs comme ça il en existe partout, c'est lors de tests que l'on s'en rends compte. Mais un test ne peut pas être exhaustif, et il arrive qu'il faille attendre l'usage pour le voir.
On découvre tous les jours des failles partout, l'open-source est le seul moyen de se rendre compte du problème.

[lilington]

En effet, il n'a fallu que 9 ans

c'est ou une blague ou tout simplement de la desinformation, car dans la news on ne dis pas que la faille a ete decouverte il ya 9 ans.
la phrase dont tu te moque n'est pas:

- ce que l'on peut encore une fois mettre en avant pour un OS open-source, c'est que les failles sont rapidement decouvertes

ce qui te donnerai raison
mais plutot:

- ce que l'on peut encore une fois mettre en avant pour un OS open-source, c'est que les failles sont rapidement corrigées

ce qui te fait passer pour un troll. car oui la reaction est imediate quand la faille est decouverte


Pour en revenir a la new, je ne comprend pas trop le probleme avec GOTO dans ce bug.
c'est pas parcequ'il a utiliser goto qui a probleme mais a cause de l'etiquette choisis c'est un peut comme si on disait de ce code (suivant) qu'il faut plus utiliser if parce qu'il ya un bug:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if(test()==EXIT_SUCCESS)
   error();
else
{
 ...
}

visiblement la personne qui ecrira ce code aura fait une erreur, mais c'est pas la faute a 'if'.
la diabolisation de goto m'etonnera toujours. Le veritable probleme de goto c'est qu'il rend le code illisible. mais il y a des cas ou il rend le code plus simple a lire.
le truc c'est de l'utiliser avec parcimonie et reflexion.

[jlliagre]

ce qui te fait passer pour un troll. car oui la reaction est imediate quand la faille est decouverte

C'était juste une réponse un peu ironique car rien ne dit que cette faille n'était pas connue et exploitée depuis longtemps. Je suis d'accord avec toi pour dire qu'elle a été corrigée rapidement mais seulement après avoir été rendue publique. Je suis aussi tout à fait d'accord avec le fait que "goto" n'y est pour rien (voir le post précédant mon "troll" ).

[lilington]

tu as tout a fait raison, faudrait que moi aussi je change le mot decouverte par l'expression rendu publique. en effet, il est possible que la faille aie ete decouverte il y a 9 an et bien exploite en douce puis seulement redu publique recement.

sinon ce qui me gene c'est les titres racoleurs

GnuTLS : Un GoTo responsable d'une faille critique

goto n'est responsable de rien du tout. le titre doit plutot etre du genre

Une erreur d'inattention responsable du faille critique

[marsupial]

En effet, il n'a fallu que 9 ans

Il aura fallu 9 ans pour découvrir la faille, mais moins de 24h pour la boucher.

Le monde propriétaire vit sur une foule de failles 0-day qui datent parfois des années 80 ( non je n'exagère pas ) auxquelles il faut souvent des mois de négociations pour que l'éditeur accepte de se pencher dessus.

Une maxime chez le support MS : "ce qu'utilisateur ne voit pas, utilisateur ne sait pas."
Bref, mettez la poussière sous la tapis, tant que ça n'empêche pas les sous de rentrer dans les caisses, on s'en tape.

[jlliagre]

Il aura fallu 9 ans pour découvrir la faille, mais moins de 24h pour la boucher.

s/découvrir la faille/que la faille soit rendue publique/
La réactivité suite à cette annonce a été en effet très bonne mais il ne faut pas se faire trop d'illusions, il est plus que probable qu'une écrasante majorité des systèmes contenant la bibliothèque vulnérable n'ont pas été mis à jour ...

[Pelote2012]

C'est balot ... On ne dit jamais assez : un code avec Goto : pas bien. En programmation, à l'école si on avait le malheur d'en faire un ...
Dommage que ce genre d'erreur se produise, alors qu'il y a presque 50 ans qu'on dit de ne pas le faire ... c'est comme boire ou conduire

[jlliagre]

C'est balot ... On ne dit jamais assez : un code avec Goto : pas bien.

La faille n'avait pas grand chose à voir avec le fait que c'était un goto, mais surtout avec le fait que le goto n'était pas dirigé vers le bon endroit.

[lilington]

C'est balot ... On ne dit jamais assez : un code avec Goto : pas bien. En programmation, à l'école si on avait le malheur d'en faire un ...
Dommage que ce genre d'erreur se produise, alors qu'il y a presque 50 ans qu'on dit de ne pas le faire ... c'est comme boire ou conduire

Ce qu'on apprend a l'ecole c'est la verite du moment. aujourd'hui tu as internet et tu dois pouvoir te renseigner sur l'origine de la proscription de GOTO, et la tu seras supris.
goto n'est dangereux du tout, les gens qui ont fait les programmes scolaire se sont arrete a un article :

En 1968, Dijkstra a lancé un pavé dans la mare, remettant en question l'ordre établi et proposant de faire table rase du goto. Dijkstra a publié un papier intitulé A case against the goto statement, mais que que Wirth, alors rédacteur en chef des Communications of the ACM a changé en courrier au rédacteur en chef, en lui donnant par la même occasion un titre destiné à devenir célèbre, Go To Statement Considered Harmful

en ce qui concerne goto toujours

L'article de Knuth montre qu'il n'y a pas besoin d'insérer des goto pour obtenir un programme illisible. Il montre comment émuler les goto avec une boucle et une structure conditionnelle et il fait remarquer à juste titre que le programme obtenu est encore moins lisible que le programme d'origine avec des goto (construction due à Jacopini). Remarquons que Knuth réfute ainsi la partie médiane de l'article de Dijkstra en montrant que le système d'index textuels et dynamiques ne permet pas à un humain de mieux comprendre le fonctionnement du programme.

et on rajoute ce ci

Quand on y réfléchit bien, nous sommes entourés d'ustensiles et d'engins qui, mal utilisés, sont dangereux voire létaux mais qui, dans des conditions normales d'utilisation, sont inoffensifs ou presque : couteaux, ciseaux à bouts pointus, tondeuses, prises électriques, etc. Pour les programmeurs, il ne faut pas oublier d'ajouter goto à la liste

Pour conclure je cite encore ceci

Les deux gourous ont tiré des conclusions différentes, que je présenterai au moyen d'une métaphore. Pour Dijkstra, puisque certaines personnes se sont intoxiquées en ingérant de l'eau de Javel, il faut interdire totalement la commercialisation de ce produit et le réserver aux chimistes professionnels. Pour Knuth, il faut vendre l'eau de Javel dans des récipients avec des bouchons de sécurité tels qu'un enfant de moins de 7 ans ne puisse pas l'ouvrir et il faut que les parents instruisent leurs enfants pour leur présenter les dangers de l'eau de Javel et les précautions d'emploi.

Personnelement j'utilise GOTO et il y a jamais plus de 1 goto dans une fonction et c'est seulement dans 2 cas:
1 des boucles tres fortement inbrique
2 dans une fonction ou il y a beaucoup de free() a faire un goto clean_and_exit vaut mieux qu'une disaine de if()free(a);free(b)...free(z); non?

aulieu de dire evite goto, faut dire dire aux gens pourquoi CERTAIN demande de l'eviter et leur montrer comment bien utiliser l'outils puissant qu'il est

[chrtophe]

Bien dit les gars.

Je suis pas développeur pro, mais le goto, c'est quand même plus souple. Le secret a été donné : parcimonie.
Il a été crée pour des usages bien précis bien expliqué par lilington.

Si on est pas rigoureux, effectivement, il vaut mieux le bannir. Mais même la rigueur n’empêche pas les bugs.
Avec le monde libre, quand on développe, on est relu par plusieurs personnes et pourtant personne a vu. Mais combien de lignes font le source ?

Personnellement, je pense que d'utiliser ce type de bibliothèque restera plus sûr que ma propre implémentation.

"Une erreur d'inattention responsable du faille critique", c'est pas assez racoleur. Avec tout le bazar qui est fait avec ce genre d'évènement, il est impossible de connaitre les réelles conséquences. Est-ce une bibliothèque utilisée tous les jours ? par tout le monde ?

En région parisienne, il y a en permanence des agressions, je me suis jamais fait agresser. C'est pas forcément plus risqué qu'ailleurs mais les médias ne parle que de ça.