GnuTLS : un GoTo responsable d'une faille critique
Qui existerait depuis 2005 dans la bibliothèque très utilisée sous Linux

Le , par Arsene Newman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de xurei xurei - Membre actif https://www.developpez.com
le 07/03/2014 à 14:21
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...
Avatar de Naoki-kun Naoki-kun - Membre régulier https://www.developpez.com
le 07/03/2014 à 14:49
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.
Avatar de DrHelmut DrHelmut - Membre habitué https://www.developpez.com
le 07/03/2014 à 15:18
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 !
Avatar de xurei xurei - Membre actif https://www.developpez.com
le 07/03/2014 à 15:36
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.
Avatar de jlliagre jlliagre - Modérateur https://www.developpez.com
le 07/03/2014 à 15:48
Citation Envoyé par DrHelmut  Voir le message
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.
Avatar de jlliagre jlliagre - Modérateur https://www.developpez.com
le 07/03/2014 à 15:50
Citation Envoyé par Naoki-kun  Voir le message
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
Avatar de Njibhu_ Njibhu_ - Futur Membre du Club https://www.developpez.com
le 08/03/2014 à 0:20
"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).
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 08/03/2014 à 20:04
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
Avatar de Arsene Newman Arsene Newman - Expert éminent sénior https://www.developpez.com
le 09/03/2014 à 9:23
Citation Envoyé par Njibhu_  Voir le message
"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/
Avatar de abriotde abriotde - Membre éclairé https://www.developpez.com
le 10/03/2014 à 14:50
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.
Offres d'emploi IT
Développeur confirmé full stack ruby
LZRECRUITING - Ile de France - Paris (75009)
Ingénieur Systèmes / Release Manager (H/F)
FULLSIX France - Ile de France - Levallois-Perret (92300)
FR-ATS Rennes- Ingénieur Réseau (H/F)
Atos Technology Services - Bretagne - Rennes (35000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil