Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Ghost : la nouvelle faille critique qui fait trembler Linux

Ghost in the shell
Internet 5 min
Ghost : la nouvelle faille critique qui fait trembler Linux

Qualys, une société spécialisée dans la sécurité sur internet, vient de publier un billet dans lequel elle dévoile l'existence d'une importante faille de sécurité dans la bibliothèque glibc de Linux. Corrigée depuis 2013, elle est encore présente dans de nombreux systèmes et pourrait être exploitée à distance, simplement via un email piégé. Explications.

Alors que l'épisode Heartbleed est encore en mémoire, une nouvelle faille sème le trouble dans le petit monde de la sécurité et du libre. Elle a été découverte par la société Qualys qui publie d'ailleurs tous les détails sur son blog. Cette brèche est identifiée sous la référence CVE-2015-0235 et porte un petit nom (puisque le marketing compte aussi désormais dans le monde des failles) : Ghost.

Quand glibc permet d'obtenir, à distance, un accès complet à la machine

Elle se cache dans la bibliothèque glibc, un composant incontournable pour toutes les distributions Linux. La faille se situe plus précisément dans les fonctions gethostbyname (d'où son surnom Ghost) et gethostbyaddress qui permettent de convertir un nom de domaine en adresse IP, généralement en passant par le DNS.

Dans les grandes lignes, le principe de fonctionnement de la faille est le suivant : il est possible de créer un dépassement de tampon (buffer overflow) ce qui a pour conséquence de « permettre à des pirates de prendre à distance le contrôle complet du système, sans avoir la moindre connaissance préalable concernant les références du système ». Tous les détails ne sont pas encore connus et le prototype n'a pas encore été mis en ligne par Qualys. La société explique que cela sera fait ultérieurement, notamment afin de laisser le temps aux services concernés de se mettre à jour. La mise en œuvre ne semble par contre pas spécialement compliquée selon ses équipes : « via un email piégé et envoyé sur un serveur email, nous avons obtenu un accès à distance au Shell de la machine ».

Une faille qui existerait depuis 2000 et qui aurait été corrigée en 2013

Maintenant que le tableau est posé, passons aux détails connus, en commençant par deux points relativement surprenants. Tout d'abord, la faille existerait depuis la version 2.2 de glibc qui date du 10 novembre 2000 selon Qualys, soit il y a plus de 14 ans ! Ensuite, elle aurait déjà été corrigée depuis le 21 mai 2013 au moment du passage entre les moutures 2.17 et 2.18 de glibc. Pour information, la dernière en date est la 2.21.

Mais alors, comment expliquer que la faille inquiète autant ? Qualys a sa propre réponse : « malheureusement, cela n'a pas été reconnu comme une menace à la sécurité [NDLR : les changements de version de glibc] ; en conséquence de quoi, la plupart des distributions stables avec un support long terme ont été laissés exposées, y compris Debian 7 (Wheezy ) , Red Hat Enterprise Linux 6 & 7 , CentOS 6 & 7 , Ubuntu 12.04 , par exemple ».

Bien évidemment, les grands groupes ont été prévenus en amont par Qualys et ont d'ores et déjà mis en ligne des mises à jour. C'est par exemple le cas de Redhat qui a déployé toute une panoplie de correctifs pour ses différents systèmes d'exploitation, d'Ubuntu 10.04 LTS et 12.04 LTS et de Debian Squeeze et Wheezy.

Les NAS et plus largement tous les systèmes Linux sont également concernés

Notez que cela ne concerne pas que les serveurs. Tous les systèmes informatiques exploitant une base Linux et une connexion réseau peuvent potentiellement être touchés par Ghost s'ils n'intègrent pas la bonne version de glibc. C'est donc le cas des NAS par exemple qui, comme pour la faille Heartbleed, ne sont pas spécialement épargnés.

Les fabricants n'ont pas encore communiqué sur la question, à l'exception du français Ve-hotech qui annonçait dès hier soir avoir mis en ligne une mise à jour 5.1.1 de son interface. Si vous avez activé les mises à jour automatiques elle devrait déjà être en place. Si ce n'est pas le cas, il faudra la lancer manuellement. Nous tenterons de revenir sur la réaction de chacun dans les heures et les jours qui viennent.

Des fonctions « dépassées depuis longtemps » et qui « ne devraient plus être utilisées » 

Pire encore, comme le précise Stéphane Bortzmeyer son blog, les fonctions dont il est aujourd'hui question (gethostbyname et gethostbyadress) « sont dépassées depuis longtemps et ne devraient plus être utilisées, notamment parce qu'elles ne permettent pas de faire de l'IPv6 ». Il ajoute même que, « depuis plus de quinze ans  », il convient d'utiliser getaddrinfo à la place. Il rejoint d'ailleurs l'analyse de Qualys qui évoque des « fonctions obsolètes avec l'avènement de l'IPv6 », mais aussi celle d'Errata Security qui préconise d'utiliser getaddrinfo à la place de gethostbyname.

Quoi qu'il en soit, cela n'est pas sans soulever une série de questions : « les fonctions officiellement remplacées par des meilleures ne sont pas forcément aussi bien maintenues, et on peut penser que les failles n'y sont pas aussi vite repérées et corrigées. Les programmes utilisant les anciennes API ont donc plus de chance d'avoir des failles de sécurité comme Ghost ». En plus de se mettre à jour, il est peut-être donc temps de penser à changer d'API au passage et d'être vigilant dans les semaines qui viennent.

Après le temps des mises à jour viendra sans doute, comme pour OpenSSL dans le cas d'Heartbleed, celui de la remise en question des procédures et de l'attitude de chacun face aux mises à jour et à l'utilisation de vieilles fonctionnalités.

281 commentaires
Avatar de jeanfig INpactien
Avatar de jeanfigjeanfig- 28/01/15 à 08:26:23

Après Windows et Mac OS X ces derniers jours, on a le trio au complet.

Avatar de vloz INpactien
Avatar de vlozvloz- 28/01/15 à 08:26:49

Elle est oppressante la video, avec la tete du mec qui s'avance par a-coup... :)

Avatar de CryoGen Abonné
Avatar de CryoGenCryoGen- 28/01/15 à 08:28:27

C'est malin de ne pas mettre à jour des composants relativement critique quand même...

Mon PC sous Linux utilise Gentoo, la version stable de la GLIBC est la 2.19 (et 2.20 en instable) donc tout va bien :smack:

D’ailleurs il y a une faute dans l'article, la dernière version (stable) de la glibc est 2.20. Signalé :)

Édité par CryoGen le 28/01/2015 à 08:31
Avatar de touitboy Abonné
Avatar de touitboytouitboy- 28/01/15 à 08:34:17

Bon le titre de l'article est quand même nettement plus alarmiste que le fond : la faille est corrigée sur un bonne partie du matériel tournant sous linux visiblement.

Par contre il est clair que ça rappelle l'importance du suivi logiciel dans le choix d'un type de hardware, car moins le support est soutenu, plus notre système est vulnérable.

Avatar de Nikodym INpactien
Avatar de NikodymNikodym- 28/01/15 à 08:34:52

Linux ? glibc ?
Les articles PCI deviennent de plus en plus approximatifs, pour rester gentil.

Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 28/01/15 à 08:35:36

Il faut relativiser un peu la phrase suivante « permettre à des pirates de prendre à distance le contrôle complet
du système, sans avoir la moindre connaissance préalable concernant les
références du système »
 
Je n’ai vu nulle part mentionner d’élévation de privilège. Bon, on peut faire du dégât quand même, hein, mais pas « prendre le contrôle complet du système ». Ouvrir un shell sur une machine distante, c’est bien et c’est déjà énorme. Pour le contrôle complet, il faut le faire avec des droits root :).

Avatar de Nikodym INpactien
Avatar de NikodymNikodym- 28/01/15 à 08:36:21

En plus, ça vient donner des leçons sur l'histoire de VLC. :roll:

Avatar de Obidoub Abonné
Avatar de ObidoubObidoub- 28/01/15 à 08:36:22

Correctif dispo depuis hier pour Debian.

Avatar de Commentaire_supprime Abonné
Avatar de Commentaire_supprimeCommentaire_supprime- 28/01/15 à 08:36:31

Bon, j'attends la réaction de Synology, la plus importante pour moi (NAS accessible en WAN)...

Pour Linux Mint 17 et LMDE, ça doit être fait depuis longtemps avec la bonne version, comme aussi mon Mageïa 4, et mes deux autres NAS (un Thecus et un Netgear) ne sont pas accessibles en WAN.

Question au passage : OpenElec utilise t-il glibc ?

Édité par Commentaire_supprime le 28/01/2015 à 08:38
Avatar de Minikea INpactien
Avatar de MinikeaMinikea- 28/01/15 à 08:37:41

pour le coup, le système de rolling release d'Arch est très bon pour la sécurité (moins pour la stabilité, de temps en temps, c'est funky! :D ). je suis en 2.20 depuis le 29/12/14 donc on peut en déduire que la version 2.18 a été déployée assez vite après sa sortie, donc faille corrigée depuis un an, au moins. de plus, je suis d'accord pour confirmer que ces fonctions sont obsolètes!

Il n'est plus possible de commenter cette actualité.
Page 1 / 29