Ghost : la nouvelle faille critique qui fait trembler Linux

Ghost : la nouvelle faille critique qui fait trembler Linux

Ghost in the shell

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

28/01/2015 5 minutes
281

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

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

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

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

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

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (281)


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


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


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 <img data-src=" />



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


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.


Linux ? glibc ?

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


Il faut relativiser un peu la phrase suivante «&nbsp;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 »

&nbsp;

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 :).


En plus, ça vient donner des leçons sur l’histoire de VLC. <img data-src=" />


Correctif dispo depuis hier pour Debian.


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 ?


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! <img data-src=" /> ). 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!








Commentaire_supprime a écrit :



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 ?









Pour openelec c’est la version 2.20 depuis la OE4.2.



Qualys explique avoir développé un exploit permettant d’obtenir un shell distant via Exim. Et qu’il y a des binaires setuid vulnérables, donc du localroot. Plus d’info là :http://www.openwall.com/lists/oss-security/2015/01/27/9








Nikodym a écrit :



Linux ? glibc ?

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









Nikodym a écrit :



En plus, ça vient donner des leçons sur l’histoire de VLC. <img data-src=" />





Dans ce cas là, le mieux c’est que tu partages ta science avec tout le monde…



Pour ma part je suis en&nbsp; 2.13-38+deb7u7 sur la mienne et il ne me propose pas de maj :‘( (ou alors j’ai rien compris <img data-src=" />)


Le problème ce n’est pas la faille, c’est que ça fait 2 ans qu’elle est corrigée et que les correctifs ne sont pas disponibles sur tous les OS, notamment les OS pro comme Red Hat.



En ce qui concerne les OS populaires grand public comme Ubuntu, les versions touchées sont quand même anciennes (2012).


il va sûrement faire son pointilleux et dire que glibc est sur tous les système à base d’unix, ou bien qu’on dit GNU-Linux, ou bien que l’on parle de GNU libc…



bref, un truc d’intégriste barbu… <img data-src=" />



par contre ça serait intéressant de savoir si les autres implémentations de la librairie libc (celle de BSD par exemple) sont impactées, bien que j’imagine que non, puisqu’on parle que de glibc.


Trembler, trembler… Les principales distributions soit disposent déjà de la mise à jour, soit utilisent une version déjà corrigée.



Maintenant c’est plus un problème avec les applications qui ne respectent pas les normes POSIX. La fonction a déjà été marquée comme “deprecated” en 2001, et retirée de la norme POSIX en 2008. Retrouver des composants qui utilisent ou proposent encore ces fonctions en 2015 est aberrant, même pour une institution comme Debian.








neves a écrit :



Qualys explique avoir développé un exploit permettant d’obtenir un shell distant via Exim. Et qu’il y a des binaires setuid vulnérables, donc du localroot. Plus d’info là :http://www.openwall.com/lists/oss-security/2015/01/27/9





Merci pour le lien. Ça confirme que les containers genre lxc ont de l’avenir :).



Tu as la version qui a été déployée hier pour colmater la faille. <img data-src=" />



https://security-tracker.debian.org/tracker/CVE-2015-0235








white_tentacle a écrit :



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 :).







La faille permet d’avoir les droits roots en la combinant avec potentiellement d’autres failles connues et non corrigées ou juste bloquées en éxecution à distance (mais pas locale) plutôt que de patcher.









white_tentacle a écrit :



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 :).





exactement, ça ne permet que d’ouvrir un shell sous l’utilisateur du service corrompu (celui qui fait tourner le service mail par exemple)









obibann a écrit :



Le problème ce n’est pas la faille, c’est que ça fait 2 ans qu’elle est corrigée et que les correctifs ne sont pas disponibles sur tous les OS, notamment les OS pro comme Red Hat.







C’est pourtant très logique : sur les distribs “pro” comme Red Hat, seuls les correctifs de sécurité sont backportés. Et comme ce soucis n’avait pas été étiqueté en tant que problème de sécurité, le correctif n’a jamais intégré ces distribs.



Ah bin merci de l’info, je vais garde ce site au cas où ça m’évitera de passer pour un c ^^”


C’est surtout que ça rappel l’importance de faire des mises à jour, des paliers “réguliers” sur les infras, …








geekounet85 a écrit :



il va sûrement faire son pointilleux et dire que glibc est sur tous les système à base d’unix, ou bien qu’on dit GNU-Linux, ou bien que l’on parle de GNU libc…



bref, un truc d’intégriste barbu… <img data-src=" />



par contre ça serait intéressant de savoir si les autres implémentations de la librairie libc (celle de BSD par exemple) sont impactées, bien que j’imagine que non, puisqu’on parle que de glibc.





<img data-src=" /> Si c’est vraiment ça, c’est vraiment pour couper les cheveux en quatres…



Encore une fois, ce qui pose soucis le plus dans cet histoire, c’est le délai de MAJ. Une faille dans un composant si essentiel (pour l’instant si je comprends bien, IPv6 is coming) met des années a être patchée alors que cela semble sérieux.



Je suis un utilisateur de Linux. (un peu plus mais on ne va pas s’étaler) <img data-src=" />



Je vois le titre de la news, je me dis “WHAT??! Comment se fait-il qu’une news PCI apparaisse sur une faille dans Linux et ne sois pas déjà au courant ?”

Je clique.

Le problème est dans la glibc.

Je ne suis en fait pas concerné car ma ferme utilise musl-libc et mes petits composants dietlibc. <img data-src=" />



En ce qui concerne VLC. Il n’y avait pas une news qui parlait d’une faille qui ne leur était pas imputable et qui dénonçait le manque de sérieux de celui qui a publié le billet ? <img data-src=" />








Commentaire_supprime a écrit :



Question au passage : OpenElec utilise t-il glibc ?







le 04/10/2014 ils sotn passés de eglibc vers glibc (bon en version 2.20 donc théoriquement pas de soucis)



On s’en fout, tout le monde a compris le propos.



Tu veux faire quoi ? Parler de “GNU” au lieu de “Linux”… genial sauf que les 34 des gens (et meme des geeks) ne saura meme pas de quoi il retourne et n’aura pas compris l’importance de la faille.



Franchement, ce chipotage sur des sites d’actu grand public, ca fait plus de 15 ans qu’on y a droit et ca fait plus de 15 ans que ca me gonfle severe.

Sur des sites specialisés, je veux bien qu’on chipote mais sur NXI, serieux, ca n’a AUCUN interet…








KP2 a écrit :



On s’en fout, tout le monde a compris le propos.



Tu veux faire quoi ? Parler de “GNU” au lieu de “Linux”… genial sauf que les 34 des gens (et meme des geeks) ne saura meme pas de quoi il retourne et n’aura pas compris l’importance de la faille.



Franchement, ce chipotage sur des sites d’actu grand public, ca fait plus de 15 ans qu’on y a droit et ca fait plus de 15 ans que ca me gonfle severe.

Sur des sites specialisés, je veux bien qu’on chipote mais sur NXI, serieux, ca n’a AUCUN interet…





C’est ton opinion. <img data-src=" />









Nikodym a écrit :



Linux ? glibc ?

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



C’est effectivement un gros copié-collé de sites anglais avec un titre un poil plus racoleur.

Maintenant, ça reste de l’info et je ne vois pas ce qu’il y a d’approximatif en dehors du fait que glibc n’est pas forcément rattaché à linux et donc que la faille concerne cette lib avant de pouvoir parler d’OS.









seboss666 a écrit :



Maintenant c’est plus un problème avec les applications qui ne respectent pas les normes POSIX. La fonction a déjà été marquée comme “deprecated” en 2001, et retirée de la norme POSIX en 2008. Retrouver des composants qui utilisent ou proposent encore ces fonctions en 2015 est aberrant, même pour une institution comme Debian.





Il faudrait un projet qui scanne les logiciels pour voir ceux qui utilise encore des fonctions obsolètes. Pour marquer ces programmes comme étant eux-même obsolète. C’est pas toujours évident sur un gros code C de détecter ce genre de problème.



La faille est dans la glibc mais des systèmes Linux ne l’ont pas corrigé.

Donc ce sont ces Linux qui sont touché et donc affecté par cette faille. Le titre n’est pas faux.


Bof…

Docker eux meme disent que l’isolation n’est pas aussi parfaite que la virtualisation et qu’il ne faut pas compter sur les containers pour la securité.



Et puis, c’est toujours pareil : il faut savoir ce qu’on veut proteger au final. Si le besoin de protection est sur les données, t’as beau avoir un container, si l’attaquant rentre dans ta base directement ou via l’applicatif ou via Ghost, t’es niqué quand meme…








NeoYoH a écrit :



Pour ma part je suis en&nbsp; 2.13-38+deb7u7 sur la mienne et il ne me propose pas de maj :‘( (ou alors j’ai rien compris <img data-src=" />)





pluzun.



Et le “apt-get update” date d’il y a 5 minutes.

&nbsp;



Les systèmes basés sur Linux n’utilisent pas tous cette bouse de glibc…


il y a t il d’autres systèmes que ceux basés sur linux qui peuvent utiliser cette bouse comme tu dis ?








Commentaire_supprime a écrit :



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





La faille se situe dans les API “gethostbyname” et “gethostbyaddr” qui sont des APIs non compatible IPV6 (voir ici)

Tous les composants natif du Linux de Synology (DSM) sont (à ma connaissance) compatibles IPV6 et il y a peu de chances que ces vieilles APIs soient encore effectivement utilisées sur ces équipements.

Un patch sera malgres très certainement rapidement diffusé (ne serait-ce que pour protéger des packages tiers utilisant ces fonctions) mais faut pas paniquer non plus.

Par exemple je viens de vérifier (via objdump -T) , sur mon syno, le serveur apache ne fait pas appel à ces fonctions.



&nbsp;









KP2 a écrit :



Bof…

Docker eux meme disent que l’isolation n’est pas aussi parfaite que la virtualisation et qu’il ne faut pas compter sur les containers pour la securité.



Et puis, c’est toujours pareil : il faut savoir ce qu’on veut proteger au final. Si le besoin de protection est sur les données, t’as beau avoir un container, si l’attaquant rentre dans ta base directement ou via l’applicatif ou via Ghost, t’es niqué quand meme…





Oui, ça fait de la mitigation, pas de la sécurité absolue. De toute façon, la sécurité absolue, ça n’existe pas (les hyperviseurs, que ce soit kvm ou xen, ont eux aussi régulièrement des failles — je ne suis pas sûr pour celui de Microsoft, qui a fait l’objet de preuve de programme). Donc toute technique qui rend plus complexe l’exploitation d’une faille est bonne à prendre.









cyrano2 a écrit :



Il faudrait un projet qui scanne les logiciels pour voir ceux qui utilise encore des fonctions obsolètes.&nbsp;





Voir du coté de “objdump” (à appliquer récursivement sur les shared libs dépendantes trouvées par un ldd des familles). Quelques lignes de script.









brazomyna a écrit :



pluzun.



Et le “apt-get update” date d’il y a 5 minutes.

&nbsp;





La version 2.13-38+deb7u6 et vulnérable.

La 7u7 corrige ces bugs :https://lists.debian.org/debian-security-announce/2015/msg00025.html



Oui, de la meme facon que dire que les articles PCI deviennent de plus en plus approximatifs est TON opinion…



Moi, au contraire, je trouve cet article plutot bien documenté et complet. Bien plus que la plupart des articles sur ce sujet que j’ai pu lire ailleurs depuis hier. Excepté l’article original de Qualys bien sur…



Moi, je comprends le besoin de reconnaissance de GNU. Sans eux, Linux n’aurait pas beaucoup plus fait que BeOS ou Minix MAIS il faut etre un peu modéré et ne pas chercher à amener des debats inutiles aupres du grand public. Il s’en fout completement et ca n’aide pas du tout “la cause”…


Je me pose plusieurs questions:




  • combien ont encore la glibc non à jour?

  • quel est le risque réel? (dans un système de production réel, à quel moment on fait un gethostXXX en passant une donnée qui vient d’un autre système? en général c’est utilisé pour résoudre des noms depuis un fichier de config dans une grande majorité des cas, non?)

  • ils remontent jusqu’à quelle date les tests de sécurité? Ils peuvent encore trouver des bugs dans QT4 je pense, et donc faire une alerte sur plein de produits grand public (vidéos proj, TV, …)


&nbsp;Ça n’empêche que les seuls systèmes impactés par cette faille sont des systèmes Linux.

Et même plus, les Linux vulnérables sont des systèmes avec un long support donc très probablement installés sur des serveurs de production en entreprise. La faille étant publique depuis 2013 et non corrigée sur ces versions.

&nbsp;

Donc, c’est une faille critique qui affecte les systèmes Linux, qui est potentiellement présente dans plein d’entreprise, et qui est publique depuis 2013. Non le titre de NXI n’est pas alarmiste ni approximatif.


Donc en gros il faut avoir un serveur de mail fonctionnel sur sa machine ?








geekounet85 a écrit :



il va sûrement faire son pointilleux et dire que glibc est sur tous les système à base d’unix, ou bien qu’on dit GNU-Linux, ou bien que l’on parle de GNU libc…



bref, un truc d’intégriste barbu… <img data-src=" />



par contre ça serait intéressant de savoir si les autres implémentations de la librairie libc (celle de BSD par exemple) sont impactées, bien que j’imagine que non, puisqu’on parle que de glibc.



C’est une erreur d’implémentation, pas de conception. Donc seule glibc est atteinte. (A part si les autres lib font du c/c du code de glibc).









geekounet85 a écrit :



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! <img data-src=" /> ). 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!





Ben moi j’ai toujours un fantôme vert dans les applications système de ma manjaro <img data-src=" />



pied dans le plat on :

Android c’est sur une base linux et c’est touché ou pas ?

pied dans le plat off








bablight a écrit :



il y a t il d’autres systèmes que ceux basés sur linux qui peuvent utiliser cette bouse comme tu dis ?



hurd



Pour ma part, à la maison :

PC de bureau sous Debian Testing, glic 2.19 donc non vulnérable.

PC portable sous Linux Mint 17, glibc 2.19 donc non vulnérable.

Serveur sous Debian 7 Stable, mise à jour dispo ce matin.



Au boulot :

PC sous Ubuntu 14.04, glibc 2.19 donc non vulnérable.







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.





La version stable d’Ubuntu est actuellement la 14.04, et non la 12.04.

Certes la 12.04 est toujours supportée, mais la présenter comme «distribution stable» est faux.











obibann a écrit :



Le problème ce n’est pas la faille, c’est que ça fait 2 ans qu’elle est corrigée et que les correctifs ne sont pas disponibles sur tous les OS, notamment les OS pro comme Red Hat.







+1 <img data-src=" />



J’entends dans la vidéo que la faille a été découverte en 2010 (enfin si j’ai bien compris parce que sa façon de parler est…bref j’aime pas).

Ça fait quand même 3 ans pour la corriger.

Je réinstalle mon OS environ tous les 6 mois mais je trouve ce temps de correction long tout de même.








trash54 a écrit :



pied dans le plat on :

Android c’est sur une base linux et c’est touché ou pas ?

pied dans le plat off





Non Android n’utilise pas glibc.



De l’intérêt de faire la différence entre Gnu et Linux.



peut-être, mais les système qui utilisent glibc sont principalement des linux (hormis certains bidouilleurs qui ne font pas ça sur de la prod, ou bien ça mérite de tomber! <img data-src=" /> ). et les systèmes qui utilisent une version glibc non mise à jour sont des linux en support étendu qu’on ne touche pas mis à part les patch de sécurité quand on y pense, et cette faille n’ayant pas été flaggé critique, elle ne rentre pas dans les patchs de sécurité.








brice.wernet a écrit :



Je me pose plusieurs questions:



 - combien ont encore la glibc non à jour?     

- quel est le risque réel? (dans un système de production réel, à quel moment on fait un gethostXXX en passant une donnée qui vient d'un autre système? en général c'est utilisé pour résoudre des noms depuis un fichier de config dans une grande majorité des cas, non?)

- ils remontent jusqu'à quelle date les tests de sécurité? Ils peuvent encore trouver des bugs dans QT4 je pense, et donc faire une alerte sur plein de produits grand public (vidéos proj, TV, ...)







Je vois bien un endroit, les serveurs de passage d’ordre en bourse (côté client et côté bourse).

Mais c’est vrai que le fichier de conf, couvre la majorité des cas (mais pas les plus sophistiqués).



“Donc toute technique qui rend plus complexe l’exploitation d’une faille est bonne à prendre.”



Pas nécessairement…



Comme je disais, il faut savoir ce qu’on veut proteger. Ca sert a rien de surproteger des trucs qui ont un interet faible ou moyen. Et il faut pas non plus oublier l’exploitation d’un service.

Si tu empiles les couches de securité, tu prends le risque d’augmenter serieusement la complexité de ton infra et donc tu augmentes le risque de panne.

Or, avant qu’une chose fonctionne d’une maniere securisée, il faut qu’elle fonctionne avant tout…



La securité, c’est comme tout : ca a des avantages (pleins) et des inconvenients. Et il faut peser le pour et le contre pour chaque elements qu’on ajoute. Si on met en place une immonde usine a gaz pour passer son niveau de securité de 99,87% a 99,89%, il y a interet de bien evaluer les couts et la charge d’exploitation supplementaire que ca va amener et le mettre en rapport avec le risque que ca couvre.

Il ne faut pas faire de la securité pour le plaisir de faire de la securité. Il faut faire de la securité pour proteger des composants ou des données bien definis.


Tout dépend du process mémoire qui exécute Ghost. Si c’est un deamon lancé sous compte root, t’as tout gagné.








m1k4 a écrit :



Donc en gros il faut avoir un serveur de mail fonctionnel sur sa machine ?





Un serveur de mail qui utilise les vielles API de la glibc (comme Exim par exemple)



Non, le serveur de mail n’est qu’un exemple parmi d’autre… L’impact est vraiment enorme et c’est tres grave comme faille.








Winderly a écrit :



J’entends dans la vidéo que la faille a été découverte en 2010 (enfin si j’ai bien compris parce que sa façon de parler est…bref j’aime pas).

Ça fait quand même 3 ans pour la corriger.

Je réinstalle mon OS environ tous les 6 mois mais je trouve ce temps de correction long tout de même.





Ils ont découvert le bug, mais il n’a pas été identifié comme faille de sécurité.



D’où le soucis que ça n’est pas été backporté par les distrib en lts puisqu’elles ne portent que les màj de sécu. Il y a eu un soucis de classification quand le bug a été découvert et ça c’est problématique.



Hurd si je ne dis pas de bêtises.


Oui, la Terre est plate. <img data-src=" />


libc utilisée par Android







WP a écrit :



The Bionic libc is a derivation of the BSD’s standard C library code that was originally developed by Google for their Android[2] operating system based on the Linux kernel.





c’est marrant parce qu’il y a aussi l’inverse : glibc avec un kernel BSD. <img data-src=" />



Android p’tet … mais le noyau en dessous qui lance la VM.

Et puis il ne faut pas oublier qu’une grande partie de la libc est compilée dans le noyau en plus du .so pour l’espace utilisateur.


Mais euh pas sympa de couper court comme ça à ma question flou <img data-src=" />



note perso : regarder ce soir sur mon OpenSuse si vulnérable ou pas








KP2 a écrit :



Non, le serveur de mail n’est qu’un exemple parmi d’autre… L’impact est vraiment enorme et c’est tres grave comme faille.





Ce qui est con c’est que ça touche une fonction obsolète (gethostbyname) qui ne devrait plus être utilisée si les dév suivaient les recommandations de l’IETF :http://www.bortzmeyer.org/3493.html (2003 quand même <img data-src=" />).



Visiblement, ca sert a rien d’essayer de causer avec toi… Tes autres commentaires sont globalement du meme acabit donc t’es juste là pour troller. Aucun interet pour moi


hé ouais… <img data-src=" />








neves a écrit :



Qualys explique avoir développé un exploit permettant d’obtenir un shell distant via Exim. Et qu’il y a des binaires setuid vulnérables, donc du localroot. Plus d’info là :http://www.openwall.com/lists/oss-security/2015/01/27/9





si il y a des binaire setuid root (déjà on évite d’en laisser) vulnérables (vite la liste), alors n’importe quel utilisateur non root normalement logué sur la machine peut devenir root quand ça lui chante : permet moi d’être sceptique.









Nikodym a écrit :



Je suis un utilisateur de Linux. (un peu plus mais on ne va pas s’étaler) <img data-src=" />



Je vois le titre de la news, je me dis “WHAT??! Comment se fait-il qu’une news PCI apparaisse sur une faille dans Linux et ne sois pas déjà au courant ?”

Je clique.

Le problème est dans la glibc.

Je ne suis en fait pas concerné car ma ferme utilise musl-libc et mes petits composants dietlibc. <img data-src=" />





Pour être honnête je me doutais de ce que tu allais répondre.



Sinon tu es la preuve même que la news a fonctionné. Il existe une faille dans certaine distrib’ linux notamment en LTS qui sont toujours largement utilisées en entreprise notamment.

Toi tu as cliqué et tu as vu que tu n’étais pas impacté: tant mieux pour toi. D’autres comme tu peux le remarquer dans les commentaires, se sont rendu compte qu’ils n’étaient pas à jour.

Le but d’information de la news est donc parfaitement atteint.





Nikodym a écrit :



En ce qui concerne VLC. Il n’y avait pas une news qui parlait d’une faille qui ne leur était pas imputable et qui dénonçait le manque de sérieux de celui qui a publié le billet ? <img data-src=" />





En ce qui concerne VLC, le manque de sérieux concernait le fait que l’auteur du billet n’a jamais aidé à la résolution du problème, que de plus la faillle n’a pu être reproduite (certainement aussi par manque de documentation) mais que dans le même temps l’auteur de la “découverte” tentait de se faire de la pub “gratos”…

Tu peux me dire quel est le lien avec la news ? <img data-src=" />









KP2 a écrit :



Non, le serveur de mail n’est qu’un exemple parmi d’autre… L’impact est vraiment enorme et c’est tres grave comme faille.





Hmm OK, jveux bien mais c’est le seul poc qu’ils ont fait à ma connaissance, donc c’est assez limité.

Mais j’imagine que oui ca ouvre la porte à d’autres exploitations de cette faille.



La glibc n’est qu’un projet parmi d’autres de GNU… GNU n’est pas un blob unique qu’on prend dans son integralité ou rien.



Donc il faut parler de la glibc comme de n’importe quelle autre bibliotheque…








mirandir a écrit :



C’est pourtant très logique : sur les distribs “pro” comme Red Hat, seuls les correctifs de sécurité sont backportés. Et comme ce soucis n’avait pas été étiqueté en tant que problème de sécurité, le correctif n’a jamais intégré ces distribs.





C’est que ça n’ait pas été étiqueté en tant que problème de sécurité qui échappe à ma logique.









TNZfr a écrit :



Android p’tet … mais le noyau en dessous qui lance la VM.

Et puis il ne faut pas oublier qu’une grande partie de la libc est compilée dans le noyau en plus du .so pour l’espace utilisateur.





Oui mais ce n’est pas glibc qui est utlisé :







geekounet85 a écrit :



libc utilisée par Android



c’est marrant parce qu’il y a aussi l’inverse : glibc avec un kernel BSD. <img data-src=" />





(Merci geekounet85 :smack)



glibc c’est un truc propre à Gnu. Android utilise très peu de truc issus de Gnu (de mémoire je dirais rien du tout même, mais je ne suis pas spécialisé là-dedans donc je ne m’avancerais pas plus que ça) et surtout pas cette librairie, et donc n’est pas impacté par ce bug. Oui ils ont une librairie équivalente mais avec une implémentation différente et donc non vulnérable à ce bug(mais surement avec d’autres bugs).



J’ai un debian 5 je fait comment? :(








Khalev a écrit :



Ce qui est con c’est que ça touche une fonction obsolète (gethostbyname) qui ne devrait plus être utilisée si les dév suivaient les recommandations de l’IETF :http://www.bortzmeyer.org/3493.html (2003 quand même <img data-src=" />).





Quand quelque chose marche on évite de le modifier ^^”

Et si ça fonctionne depuis 2003, c’est que ça doit vachement bien marcher :)



comme disait Kahlev, android utilise Bionic&nbsp;, une version allégé de la libc &nbsp;(et si j’ai bien compris, ce n’est pas un fork, pour éviter la GPL, et en faire une code sous License BSD)



Ca veut pas dire que c’est impossible qu’android ne soit pas touché, mais à mon avis si il l’était on en aurait entendu parler… on verra bien&nbsp;<img data-src=" />








KP2 a écrit :



La glibc n’est qu’un projet parmi d’autres de GNU… GNU n’est pas un blob unique qu’on prend dans son integralité ou rien.



Donc il faut parler de la glibc comme de n’importe quelle autre bibliotheque…





Oui merci de la précision <img data-src=" />



Ouais mais pour faire des poc, il faut du temps… et les mecs ont deja fait un beau boulot en pointant la faille et en montrant les impacts. Ils ont proposé ce poc car ca devait probablement etre un des plus evident, simple a faire et representatif de la menace (envoyer un “simple” mail suffit a prendre le controle d’un serveur, ca claque !)



On verra des exploits arriver en plus grand nombre aujourd’hui et encore plus raffinés dans les jours qui viennent.








KP2 a écrit :



Bof…

Docker eux meme disent que l’isolation n’est pas aussi parfaite que la virtualisation et qu’il ne faut pas compter sur les containers pour la securité.



Et puis, c’est toujours pareil : il faut savoir ce qu’on veut proteger au final. Si le besoin de protection est sur les données, t’as beau avoir un container, si l’attaquant rentre dans ta base directement ou via l’applicatif ou via Ghost, t’es niqué quand meme…





A bon ? Pourtant c’est l’un des avantage des container : la sécurité via l’isolation des applications.

Normalement si tes donnée ne sont pas accessible au container compromis il n’aura pas accès au données.



Ici dans ce cas via ghost ca voudrait dire que tu pourrais compromettre les container contenant la faille mais ne pas contaminer le reste de la machine.









Khalev a écrit :



Ce qui est con c’est que ça touche une fonction obsolète (gethostbyname) qui ne devrait plus être utilisée si les dév suivaient les recommandations de l’IETF :http://www.bortzmeyer.org/3493.html (2003 quand même <img data-src=" />).





Ca date de 2003 et ça termine ainsi :

“L’inertie des programmeurs étant très forte, et celle des

enseignants également, on peut parier, bien que le premier RFC sur le

sujet soit vieux de onze ans, que beaucoup de cours de programmation

réseaux sont encore donnés avec la vieille interface, qui ne marche

qu’en IPv4… À l’appui de ce pari, notons que le service Code Search de Google

trouve 255&nbsp;000 occurrences de gethostbyname

contre seulement 78&nbsp;200 de getaddrinfo.”



Ce qui amène le RFC à 1992. Merci pour le lien.









Konrad a écrit :



La version stable d’Ubuntu est actuellement la 14.04, et non la 12.04.

Certes la 12.04 est toujours supportée, mais la présenter comme «distribution stable» est faux.



en quoi elle n’est pas stable? c’est une nightly, une testing?









trash54 a écrit :



pied dans le plat on :

Android c’est sur une base linux et c’est touché ou pas ?

pied dans le plat off







De toute façon si Android était touché, vu la réactivité des mises à jour des appareils, la faille ne serait pas prête d’être colmatée <img data-src=" />



OK je sors…



Si tu peux pas upgrader l’OS vers une version plus recente, tu utilises des services qui n’utilisent pas ces 2 API de la glibc, tu mets un firewall pour etre sur que rien d’autre n’est en ecoute.

Et tu pries…



Mais bon, si tu es aussi en retard, cette faille n’est qu’une menace parmi d’autres. Les services que tu fais tourner doivent avoir eux meme un gros paquet de failles deja…








Jed08 a écrit :



Quand quelque chose marche on évite de le modifier ^^”

Et si ça fonctionne depuis 2003, c’est que ça doit vachement bien marcher :)





C’est surtout que tout le monde s’en tape le cornichon de IPV6 en fait. Puisqu’à la base c’est parce que gethostbyname ne supporte que IPV4 que l’IETF a sorti ce RFC pour normaliser les fonctions équivalentes supportant IPV4 et IPV6.

En plus comme le dit Bortzmeyer, les tuto, cours et exemples n’ont pas été mis à jour en 2003, puisque si ça marche on ne corrige pas. Et on se retrouve donc avec une fonction officiellement obsolète qui continue à être utilisée 10 ans après.



Mon père a Linux Mint 11 et cette version a glibc 2.13. Vaut-il mieux qu’il mette à jour ?

Ça fait longtemps que je lui dis de mettre à jour mais il me dit toujours : “Pourquoi ? Ça marche bien et j’ai pas le temps de tout réinstaller”. Moi je ne vis plus dans la maison familiale donc je ne peux plus intervenir.

Il en fait une utilisation assez “basique” surf et bureautique.

Peut-être simplement faire un “apt-get update” ou un truc dans le genre ?&nbsp;

&nbsp;


non Android utilise la µlibc, d’ou l’écriture de la lib “libhydris” pour exploiter sur des kernel arm/glibc (sailfish, raspbian, open moko, maemo5, harmattan) les modules kernels&nbsp;&nbsp;µlibc&nbsp;écrit pour android …


C’est vrai que NXI est clairement un site généraliste <img data-src=" />



Je trouve comme toi exagérée la sortie de Nikodyn vu qu’au final le problème touche bien les distributions Linux (quoique le titre est vraiment racoleur limite Clubic), cela dit son argument a un fond de vérité.



NXI couvre de nombreux domaines d’actualité certes (et c’est pour ça qu’il plaît) mais il s’agit toujours UNIQUEMENT de domaines directement liés à l’informatique. Ce n’est donc PAS un site généraliste.



Et en tant que site spécialisé, on peut donc lui demander un niveau de précision et de rigueur supérieur sur le traitement d’un info qui ressort de son domaine.



Après perso je ne vois pas de soucis dans le traitement de la news au delà du style un tantinet plus dramatisant que nécessaire (mais c’est bon pour le clic donc ça va pour cette fois <img data-src=" />).

&nbsp;







romjpn a écrit :



Mon père a Linux Mint 11 et cette version a glibc 2.13. Vaut-il mieux qu’il mette à jour ?



Ça fait longtemps que je lui dis de mettre à jour mais il me dit

toujours : “Pourquoi ? Ça marche bien et j’ai pas le temps de tout

réinstaller”. Moi je ne vis plus dans la maison familiale donc je ne

peux plus intervenir.

Il en fait une utilisation assez “basique” surf et bureautique.

&nbsp;





Selon la news ça a été corrigé à la version 2.18 donc ton père est concerné. Perso je conseillerais la MAJ par principe mais aucune idée de l’impact potentiel (il est possible par exemple que ça implique carrément une maj de la distrib, bien plus risqué ^^). Après tu peux peut-être attendre d’avoir plus d’infos sur les réels usages possibles. Si le seul moyen d’exploitation est un mail, un peu de pédagogie limitera beaucoup les risques. :)









creatix a écrit :



J’ai un debian 5 je fait comment? :(





sudo rm -rf / && sudo apt-get install debian-8 <img data-src=" />









CoooolRaoul a écrit :



Voir du coté de “objdump” (à appliquer récursivement sur les shared libs dépendantes trouvées par un ldd des familles). Quelques lignes de script.





ou un programme basé sur Coccinelle qui transforme les appels obsolètes en appel correct.https://en.wikipedia.org/wiki/Coccinelle_%28software%29



Android utilise bionic, pas µClibc.

Grosse différence: bionic ne cherche même pas à être proche de la compatilibilité.


La version stable actuelle d’Ubuntu c’est la 14.10 … les versions débattues ici sont celles à support étendu.








bandix400 a écrit :



si il y a des binaire setuid root (déjà on évite d’en laisser) vulnérables (vite la liste), alors n’importe quel utilisateur non root normalement logué sur la machine peut devenir root quand ça lui chante : permet moi d’être sceptique.







Pour la liste des setuid root, je t’invite à faire un find sur ton système. Oui, il en reste encore.



Pour la liste des setuid root vulnérables, je t’invite à lire… le lien de mon message que tu cites…

&nbsp;



Cette technique permet d’isoler des applications mais c’est pas parfait. Et c’est justement pas “assez” parfait pour considerer que ca ameliore nettement la securité.

C’est toute la difference entre les containers et la virtualisation (sans compter les failles d’implementation bien evidemment).



Les containers ont pleins d’avantages mais si tu as un besoin fort de securité, il ne faut pas trop compter dessus. En tout cas, ca ne permet pas de se passer des grands principes de la securité (maj, maj, maj, mot de passes forts, chiffrage, etc)


Pour les desktops, il ne faut pas tomber dans la paranoia…



Si il est derriere une box operateur standard, son PC n’est pas accessible de l’exterieur donc son risque principal est le phishing, pas une attaque via cette faille.



Ce sont les serveurs publics qui vont etre visés par cette faille. C’est eux qu’il faut mettre a jour.








romjpn a écrit :



Mon père a Linux Mint 11 et cette version a glibc 2.13. Vaut-il mieux qu’il mette à jour ?

Ça fait longtemps que je lui dis de mettre à jour mais il me dit toujours : “Pourquoi ? Ça marche bien et j’ai pas le temps de tout réinstaller”. Moi je ne vis plus dans la maison familiale donc je ne peux plus intervenir.

Il en fait une utilisation assez “basique” surf et bureautique.

Peut-être simplement faire un “apt-get update” ou un truc dans le genre ?





Est-ce que s’il regarde les updates dispo il en voit une qui date de ce matin? Si oui. Qu’il l’installe, sinon le plus simple est de réinstaller le système.



Sinon tu peux tester de lui faire installer la lib avec la version patchée de debian (la 2.13-38+deb7u7), ça reste de la 2.13 et du debian, donc ça devrait pas trop poser de problèmes (à tester quand même). Mais c’est pas forcément facile à faire si on a pas l’habitude.









KP2 a écrit :



Cette technique permet d’isoler des applications mais c’est pas parfait. Et c’est justement pas “assez” parfait pour considerer que ca ameliore nettement la securité.

C’est toute la difference entre les containers et la virtualisation (sans compter les failles d’implementation bien evidemment).



Les containers ont pleins d’avantages mais si tu as un besoin fort de securité, il ne faut pas trop compter dessus. En tout cas, ca ne permet pas de se passer des grands principes de la securité (maj, maj, maj, mot de passes forts, chiffrage, etc)





Mmmh c’est évidement pas parfait. Mais ça permet bien d’améliorer la sécurité.&nbsp; De plus l’utilisation de solutions comme docker permet de largement faciliter les mises a jours (et éviter de se retrouver avec des vieux système pas mis a jours). Tu peux facilement mettre a jours le serveur hôte et les container séparément et régulièrement de manier beaucoup plus simple que sur un serveur normal.



Même une virtualisation complète ne te dispense pas des principes de sécurités basiques au passage.









KP2 a écrit :



Pour les desktops, il ne faut pas tomber dans la paranoia…



Si il est derriere une box operateur standard, son PC n’est pas accessible de l’exterieur donc son risque principal est le phishing, pas une attaque via cette faille.



Ce sont les serveurs publics qui vont etre visés par cette faille. C’est eux qu’il faut mettre a jour.





+1 aussi. Faut juste qu’il fasse gaffe à ce qu’il fait. Mais à un moment faudra quand même qu’il fasse la réinstall.



“NXI couvre de nombreux domaines d’actualité certes (et c’est pour ça qu’il plaît) mais il s’agit toujours UNIQUEMENT de domaines directement liés à l’informatique. Ce n’est donc PAS un site généraliste. ”



Oui, c’est pas lemonde.fr, je suis d’accord… neanmoins, j’estime que le debat “GNU/Linux” vs “Linux” n’a aucun interet ici car c’est pas encore assez specialisé…



Et puis, meme sur les sites hyper specialisés, je trouve vraiment que c’est un debat debile. Pour moi, les connaisseurs savent deja ce qu’ils doivent a GNU et l’importance de GNU. Et c’est le plus important.

Le reste, c’est du branlage de nouille…


Tout a fait…



De toute facon, y’a pas de recette miracle pour securiser des machines sinon ca ferait partie de la conf par defaut et on ne se poserait pas de question…



Euuuh, j’aime beaucoup le “on évite de laisser des fichiers exécutables setuid”. <img data-src=" />

Je suppose que tu visais les applis développées soi-même ?



Non, parce que, c’est un peu la base du fonctionnement du système GNU/Linux le setuid root !








ActionFighter a écrit :



sudo rm -rf / && sudo apt-get install debian-8 <img data-src=" />







C’est dépassé le sudo rm -rf /

Pour effacer correctement le système il faut installer steam ailleurs que dans son répertoire par défaut <img data-src=" />









white_tentacle a écrit :



Oui, ça fait de la mitigation, pas de la sécurité absolue. De toute façon, la sécurité absolue, ça n’existe pas (les hyperviseurs, que ce soit kvm ou xen, ont eux aussi régulièrement des failles — je ne suis pas sûr pour celui de Microsoft, qui a fait l’objet de preuve de programme).






  L'hyperviseur en prod actuel de Microsoft n'a pas fait l'objet de preuve. Les travaux autour de la vérification d'hyperviseur chez Microsoft Research/Saarlands University (principalement par Alkassar, Cohen et Schirmer et basés sur des travaux de Starostin et Tsyban) concernent un prototype simplifié et assez éloigné de l'implémentation réelle. Les éventuels travaux pour un hyperviseur réel vérifié qui pourrait venir d'eux ne sont à l'heure actuelle pas publics.     






 Un bon exemple de micronoyau vérifié est plutôt seL4 mais est plus destiné à l'embarqué qu'à la virtualisation. Après une bonne part des concepts restent les mêmes. Aujourd'hui la vérification formelle (conformité (quasi-)parfaite à une spec) d'un logiciel de ce genre, c'est possible mais ça reste méga cher (25 PY pour les 10k loc de seL4).


Le truc drôle, c’est que c’est toi, et toi seul qui évoque le sujet de la précision dans la dénomination… <img data-src=" />



Relis bien, Nikodyn n’a jamais dit “bouuuh ça va pas vous parlez de Linux au lieu de GNU/Linux” il a dit “bouuh vous parlez de Linux comme si l’intégralité des systèmes étaient touchés (genre faille kernel) alors que seule une bibliothèque pas exploitée partout est concernée.









Nikodym a écrit :



Je suis un utilisateur de Linux. (un peu plus mais on ne va pas s’étaler) <img data-src=" />





Je vois le titre de la news, je me dis “WHAT??! Comment se fait-il

qu’une news PCI apparaisse sur une faille dans Linux et ne sois pas déjà

au courant ?”

Je clique.

Le problème est dans la glibc.

Je ne suis en fait pas concerné car ma ferme utilise musl-libc et mes petits composants dietlibc. <img data-src=" />




C'est toi qui a amené ça (en donnant l'impression de vouloir réduire son propos pour le décrédibiliser, soit dit en passant, mais bon ça c'est ton affaire)...     







KP2 a écrit :



On s’en fout, tout le monde a compris le propos.




Tu veux faire quoi ? Parler de "GNU" au lieu de "Linux"... genial sauf que les 3/4 des gens (et meme des geeks) ne saura meme pas de quoi il retourne et n'aura pas compris l'importance de la faille.      






Franchement, ce chipotage sur des sites d'actu grand public, ca fait plus de 15 ans qu'on y a droit et ca fait plus de 15 ans que ca me gonfle severe.      

Sur des sites specialisés, je veux bien qu'on chipote mais sur NXI, serieux, ca n'a AUCUN interet...








Je ne sais pas si tout le monde a compris le propos de la news, ce qui est sûr c'est que tu n'as pas compris le sien... *sifflote*


Le sandboxing et l’utilisation des outils modernes du Kernel sont quand même un gros plus qui sont encore sous exploités sur Desktop et qui peuvent limiter/réduire les soucis de sécurité sur les machines.



Sur serveur ça permet déjà d’améliorer pas mal de choses et ces nouvelles technos viennent souvent accompagnées de méthodes/concepts et outils qui renforcent encore un peu plus la sécurité de l’ensemble.



Maintenant c’est comme tout y’a pas de solution miracle. Mais on peut essaye de mitiger les risques.


Le probleme sous windows est que des failles de ce genre, y’en a tous les 2 mois… Sous linux, ca arrive une fois tous les 2 ou 3 ans en moyenne.



Dernierement, on a pas eu de chance parce que c’est la 3e faille vraiment grave en qq mois mais ca faisait un paquet d’annees que rien n’etait sorti…








CryoGen a écrit :



C’est dépassé le sudo rm -rf /

Pour effacer correctement le système il faut installer steam ailleurs que dans son répertoire par défaut <img data-src=" />





C’est pas si trollesque que ça <img data-src=" />









Khalev a écrit :



C’est surtout que tout le monde s’en tape le cornichon de IPV6 en fait.

Puisqu’à la base c’est parce que gethostbyname ne supporte que IPV4 que

l’IETF a sorti ce RFC pour normaliser les fonctions équivalentes

supportant IPV4 et IPV6.

En plus comme le dit Bortzmeyer, les tuto,

cours et exemples n’ont pas été mis à jour en 2003, puisque si ça

marche on ne corrige pas. Et on se retrouve donc avec une fonction

officiellement obsolète qui continue à être utilisée 10 ans après.





&nbsp;À ce propos, comment ça se fait que tout le monde s’en foute ? Ça fait genre 8 ans qu’on annonce la saturation des IPv4, on a même eu droit aux annonces de cataclysme informatique fin 2013/début 2014 je sais plus, parce qu’il ne restait plus que quelques mois avant saturation effective, et rien n’était fait côté équipements/infra réseaux oh mon dieu internet va exploser…




Et là, j'ai l'impression que mis à part les opérateurs réseaux, l'équipement mis en vente encore aujourd'hui est encore trèèèèès majoritairement ipv4 (c'est à dire au mieux compatible ipv6 mais configuré en ipv4)?     





Ou suis-je complètement à la ramasse ?



&nbsp;      







CryoGen a écrit :



C’est dépassé le sudo rm -rf /



 Pour effacer correctement le système il faut installer steam ailleurs que dans son répertoire par défaut <img data-src=">







<img data-src=" />



Avec un système à jour (y compris sur la glibc), on ne risque rien à propos de cette faille&nbsp; précise donc. Ceci depuis à priori 2013. Sauf à avoir un matériel/système non mis à jur, que risque-t-on ? Il existe d’autres failles plus graves que cette dernière, dont heartbleed (pour ne citer que cette dernière).


Le bufferoverflow encore et toujours !

Mais bon sang quand est ce qu’on va retourner aux anciennes méthodes mainframe afin que ça n’existe plus!



C’était mieux avant ! &nbsp;<img data-src=" />

&nbsp;


je suis en partie responsable aussi. mais le principe reste le même : montrer qu’il est tellement au dessus de ça car il n’utilise plus cette lib “mainstream”







Nikodym a écrit :



Les systèmes basés sur Linux n’utilisent pas tous cette bouse de glibc…





et que donc le terme Linux n’est pas approprié parce que lui a un linux qui n’a pas glibc et que donc ce n’est pas une généralité. sauf que en règle générale c’est la glibc qui est utilisée dans les systèmes à base de noyau Linux et qu’il y a des exceptions qui ne sont donc pas impactées par l’article.



Et nous perdrions du même coup une précieuse source de trolls, débats sans fin et autres querelles de chapelle… Sans compter l’impact violent que cela aurait sur l’industrie des télécommunications (moins de botnets &gt; moins de consommation &gt; moins de personnel nécessaire pour entretenir ou développer le réseau), la disparition de tout un métier (expert en sécurité) et la disparition probable d’un bon nombre d’échoppes de pop-corn/chips…



Heureusement que ça n’arrivera jamais, finalement… <img data-src=" />


Rsync pour la suppression est plus rapide


P’tete pasque c’est trop lourd ? P’tete que le “marché” trouve que c’est plus efficace de coder tres vite comme on fait aujourd’hui avec les risques que ca comporte ?



Ce sont de vraies interrogations, pas des contradictions deguisees en questions :)








Citan666 a écrit :



Le truc drôle, c’est que c’est toi, et toi seul qui évoque le sujet de la précision dans la dénomination… <img data-src=" />



Relis bien, Nikodyn n’a jamais dit “bouuuh ça va pas vous parlez de Linux au lieu de GNU/Linux” il a dit “bouuh vous parlez de Linux comme si l’intégralité des systèmes étaient touchés (genre faille kernel) alors que seule une bibliothèque pas exploitée partout est concernée.





Et si toi tu relis bien, le “vous” c’est NXi et l’article en question…

Et la, il suffit de lire l’article dans son ensemble (et pas seulement le titre) et… miracle…



effectivement, ma mémoire m’a joué un tours; c’est bien Bionic …&nbsp;


En fait il serait plus approprié de dire “le monde linux”.



Sinon c’est tout de même un brin alarmiste :transmi: Sans compter qu’une glib touchée par la faille seule ne suffit pas à l’exploitation de cette faille, les correctifs sont déjà dispo pour la plus part des distrib vulnérables.

Donc “trembler” est un peu exagéré.



Mais je suis bien d’accord, en faire un débat à se point là pour savoir si oui ou non le titre/news de Nxi est foiré, ca va trop loin <img data-src=" />


Pour les chips, y’a encore les eternels debats “GNU/Linux” vs “Linux”, emacs vs vi, java vs .net, python vs perl, etc



Je crois que c’est un marché en pleine croissance au contraire :)








geekounet85 a écrit :



je suis en partie responsable aussi. mais le principe reste le même : montrer qu’il est tellement au dessus de ça car il n’utilise plus cette lib “mainstream”



et que donc le terme Linux n’est pas approprié parce que lui a un linux qui n’a pas glibc et que donc ce n’est pas une généralité. sauf que en règle générale c’est la glibc qui est utilisée dans les systèmes à base de noyau Linux et qu’il y a des exceptions qui ne sont donc pas impactées par l’article.





C’est ce que tu crois.

Oui je suis au dessus de tous, trop fort, le meilleur <img data-src=" />









Citan666 a écrit :



&nbsp;À ce propos, comment ça se fait que tout le monde s’en foute ? Ça fait genre 8 ans qu’on annonce la saturation des IPv4, on a même eu droit aux annonces de cataclysme informatique fin 2013/début 2014 je sais plus, parce qu’il ne restait plus que quelques mois avant saturation effective, et rien n’était fait côté équipements/infra réseaux oh mon dieu internet va exploser…




 Et là, j'ai l'impression que mis à part les opérateurs réseaux, l'équipement mis en vente encore aujourd'hui est encore trèèèèès majoritairement ipv4 (c'est à dire au mieux compatible ipv6 mais configuré en ipv4)?      






Ou suis-je complètement à la ramasse ?









Simulation d’un entretien avec le responsable matériel d’une grosse boite (et je ‘lai eu en live celui là) :





  • Techos à fond : Tu as vu qu’il y a une saturation ipv4 et qu’ipv6 ets annoncé on va faire migrer notre matos progressivement en ipv6 Patwon ?

  • Chef : Ca sert à rien ca marche

  • Techos à fond : oui mais dans le futur ca pourrait éviter les problèmes, et puis cela permettrai de faire des choses supplémentaires

  • Chef : on a rien besoin de plus c’est pas demandé

  • Techos à fond : Ben nos clients veulent que ca marche

  • Chef : et ca risque de nous couter cher il va falloir former nos équipes

  • Techos à fond : Mais de toute façon il va un jour falloir le faire non ?

  • Chef : Ca tu n’en sais rien, et puis on va devoir changer de fournisseur notre fournisseur français ne fait pas d’ipv6 (et j’aurai plus mon voyage tout frais payés en cadeau chaque année)

  • Techos à fond : … Ok,…









cyrano2 a écrit :



ou un programme basé sur Coccinelle qui transforme les appels obsolètes en appel correct.https://en.wikipedia.org/wiki/Coccinelle_%28software%29





J’avais interprété que ce qui était demandé était plus de faire un audit des binaires que patcher les sources. Mais on peut l’interpréter ainsi.



Sur les NAS ? Mais ils sont pas tous basés sur BSD ?








KP2 a écrit :



Pour les chips, y’a encore les eternels debats “GNU/Linux” vs “Linux”, emacs vs vi, java vs .net, python vs perl, etc



Je crois que c’est un marché en pleine croissance au contraire :)





D’ailleurs neovim &gt; vim &gt; vi &gt; emacs.



<img data-src=" />

&nbsp;C’est exactement ça et bien sûr&nbsp; je faisais de l’humour&nbsp;

Mais depuis qu’on fait de la logique stateless à la place de la statefull on n’arrète pas d’avoir des failles&nbsp;

le vieil adage de “la confiance n’exclut pas le controle”&nbsp; a été aboli par des questions de fric et de facilité

On finira par en crever !

Mais bon c’est la rançon du progrès

<img data-src=" />

&nbsp;








carbier a écrit :



Et si toi tu relis bien, le “vous” c’est NXi et l’article en question…

Et la, il suffit de lire l’article dans son ensemble (et pas seulement le titre) et… miracle…





Bah oui, j’ai parfaitement compris que le vous désignait l’article de NxI… Relis donc toi-même… <img data-src=" />



 Il a parfaitement le droit de critiquer le choix du titre... Car le titre est effectivement racoleur, même si fondamentalement justifié. Par ailleurs je n'avais pas l'intention de poursuivre un débat sans fin et relativement peu intéressant sur le titre (chacun son opinion), simplement clarifier la source d'un malentendu...    









XMalek a écrit :



Simulation d’un entretien avec le responsable matériel d’une grosse boite (et je ‘lai eu en live celui là) :






 - Techos à fond : Tu as vu qu'il y a une saturation ipv4 et qu'ipv6      



ets annoncé on va faire migrer notre matos progressivement en ipv6

Patwon ?



 - Chef : Ca sert à rien ca marche       

- Techos à fond

: oui mais dans le futur ca pourrait éviter les problèmes, et puis cela

permettrai de faire des choses supplémentaires

- Chef : on a rien besoin de plus c'est pas demandé

- Techos à fond : Ben nos clients veulent que ca marche

- Chef : et ca risque de nous couter cher il va falloir former nos équipes

- Techos à fond : Mais de toute façon il va un jour falloir le faire non ?






 - Chef : Ca tu n'en sais rien, et puis on va devoir changer de      



fournisseur notre fournisseur français ne fait pas d’ipv6 (et j’aurai

plus mon voyage tout frais payés en cadeau chaque année)



 - Techos à fond : ... Ok,...








C'est tellement toujours la même chose (j'hésite entre <img data-src="> et <img data-src=">)   









JoePike a écrit :



<img data-src=" />

&nbsp;C’est exactement ça et bien sûr&nbsp; je faisais de l’humour&nbsp;

Mais depuis qu’on fait de la logique stateless à la place de la statefull on n’arrète pas d’avoir des failles&nbsp;

le vieil adage de “la confiance n’exclut pas le controle”&nbsp; a été aboli par des questions de fric et de facilité

On finira par en crever !

Mais bon c’est la rançon du progrès

<img data-src=" />

&nbsp;





Justement, peut-on vraiment parler de progrès à ce compte ? <img data-src=" />



emacs &gt; all.








Citan666 a écrit :



Non, parce que, c’est un peu la base du fonctionnement du système GNU/Linux le setuid root !





C’est quand même en train d’être remplacé par les capabilities (par exemple CAP_NET_RAW qui permet à ping de ne plus être setuid root).



Bah en plus de GNU Linux, ça peut probablement toucher GNU Hurd.


Pour ceux que ça interessen, je vous conseille de lire la partie “3 - Mitigating factors” du rapport de Qualys :

http://www.openwall.com/lists/oss-security/2015/01/27/9



qui commence par

“The impact of this bug is reduced significantly by the following reasons:”



en gros c’est pas non plus une faille béante.

Elle reste difficile à exploiter et est inexploitable sur beaucoup de services.








Ksass`Peuk a écrit :



emacs &gt; all.





Donc : emacs &gt; emacs, absurde !









lincruste_2_la vengeance a écrit :



Sur les NAS ? Mais ils sont pas tous basés sur BSD ?







Les Synology c’est du Linux (sur mon DS414 : Linux DS414 3.2.40 #5022 SMP Wed Jan 7 14:18:25 CST 2015 armv7l GNU/Linux synology_armadaxp_ds414). Les QNAP pareil.



&nbsp;



Ouais mais il n’a amené sa precision que bien plus tard…



Et meme avec sa precision, c’est encore pire comme troll car le mec balance des petites remarques vagues au compte goutte pour dire au final qu’il fait partie des 0.0005% de gens qui utilisent autre chose que la glibc sur leurs systemes. Donc il trouve le moyen de chipoter sur un truc encore PIRE que le debat GNU/Linux…



Genre, pour contenter monsieur, il faudrait ajouter 30 lignes de precisions sur le fait que la faille touche les OS linux mais seulement ceux qui utilisent glibc et pas les 0.0005% qui preferent des libs alternatives completement inconnues pour leurs besoins ultra specifiques.

Genial… Si ca c’est pas un troll, je sais pas ce que c’est…


emacs &gt; Linux








JoePike a écrit :



Le bufferoverflow encore et toujours !

Mais bon sang quand est ce qu’on va retourner aux anciennes méthodes mainframe afin que ça n’existe plus!



C’était mieux avant ! &nbsp;<img data-src=" />

&nbsp;





Dans mes bras! Et même pas besoin sans aller jusqu’au mainframes, suffit de penser aux “minis” des seventies.

Je ne comprend pas non plus comment on peut&nbsp;encore aujourd’hui&nbsp;se traîner ce genre d’anomalie alors que sur des architectures&nbsp;conçues il y a plus d’une quarantaine d’années toute tentative d’exécution de code dans des segments mémoires de type données se terminait irrémédiablement par une exception.



Non, un grand nombre tournent sous linux aussi


<img data-src=" />



Ainsi qu’à ceux qui m’ont tenu au courant pour OpenElec (j’ai la 5.0, la 4.2 merdait sur mon HTPC à base de Celeron récent).


“simplement via un email piégé”

Donc ne touche que les imbéciles et ignorants qui ne savent pas repérer ce genre de mails. Et donc très peu d’impact pour les utilisateurs de Linux.








lincruste_2_la vengeance a écrit :



Sur les NAS ? Mais ils sont pas tous basés sur BSD ?





Un nas c’est juste l’utilisation que tu en fais. Tu peux en faire un sous windows si tu veux ^^



Effectivement, la faille est loin d’être aussi évidente à exploiter que ne le suggère le titre de l’article, comme résumé ici :http://lwn.net/Articles/630854/



&nbsp;

Et de l’aveu même de Qualys :

&nbsp;

Here is a list of potential targets that we investigated (they all callgethostbyname, one way or another), but to the best of our knowledge,the buffer overflow cannot be triggered in any of them:apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,vsftpd, xinetd





&nbsp;Donc oui il existe une faille (corrigée depuis 1 an 12), mais ce n’est pas une raison pour en faire des tonnes…


Android utilise bionic comme libc, donc non touché.


Oui bon, bof quoi…

&nbsp;Titre à sensation pour générer du clic.



Faille corrigée depuis 2 ans. Y a que certaines distribs à la ramasse qui ne l’ont pas corrigé (oui, je pense fortement à Redhat qui, à mes yeux, a perdu son sérieux depuis de nombreuses années)



Et si on parlait des failles existantes sous les différentes versions de windows non-corrigées. Et celles de osX, et celles d’android…

&nbsp;Y aurait beaucoup plus à s’inquiéter <img data-src=" />








ActionFighter a écrit :



sudo rm -rf / && sudo apt-get install debian-8&nbsp;<img data-src=" />



&nbsp;Ba merde alors apt-get not found&nbsp;<img data-src=" />



Nan mais l’histoire du mail, c’est quand il arrive sur un serveur de mail… Pas dans la boite du destinataire final.

Le destinataire ne voit meme pas le mail que le serveur est deja corrompu…








KP2 a écrit :



Ouais mais il n’a amené sa precision que bien plus tard…



Et meme avec sa precision, c’est encore pire comme troll car le mec balance des petites remarques vagues au compte goutte pour dire au final qu’il fait partie des 0.0005% de gens qui utilisent autre chose que la glibc sur leurs systemes. Donc il trouve le moyen de chipoter sur un truc encore PIRE que le debat GNU/Linux…



Genre, pour contenter monsieur, il faudrait ajouter 30 lignes de precisions sur le fait que la faille touche les OS linux mais seulement ceux qui utilisent glibc et pas les 0.0005% qui preferent des libs alternatives completement inconnues pour leurs besoins ultra specifiques.

Genial… Si ca c’est pas un troll, je sais pas ce que c’est…





C’est ton opinion fondée sur de fausses données qui plus est.



J’avais négocié une réinstall du serveur donc bon ça va accélérer les choses… prochaine distrib ubuntu je pense. &nbsp;Mais je pense pas être le seul coincé avec une vielle version de debian…


Nan mais laisse tomber… soit tu entres dans la discussion et tu expliques ton point de vue, soit tu cesses de répondre.

Moi aussi aussi je peux dire “Nan !” a chaque fois que je ne suis pas d’accord mais ca n’avance a rien

Ca me fait penser a mes gosses :

“- nan !




  • si !

  • nan !

  • si !

  • nan !

    …”

    Ils peuvent faire ca pendant 15 min d’affilée…










TNZfr a écrit :



La version stable actuelle d’Ubuntu c’est la 14.10 … les versions débattues ici sont celles à support étendu.



aucune version d’Ubuntu n’est stable. stable, c’est Debian : ca utilise des technos éprouvées dont on connait le fonctionnement.

Ubuntu, ce sont des LTS. et jusqu’à preuve du contraire, la 12.04 est une LTS toujours supportée.



je pense que tu n’as pas compris…



c’est lors du transit du mail, qu’il arrive a compromettre le serveur mail, ce n’est pas quand tu cliques sur un liens ou autre.

c’est bien une exploitation de faille à distance, sans avoir besoin d’action utilisateur…

&nbsp;








vloz a écrit :



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







Il a un accent Anglais aussi bon que le mien en tout cas … <img data-src=" />



Debian aussi a patchè la libc cette nuit…

Comme dit dans l’article, et plusieurs fois dans les commentaires, les principal problème vient du fait qu’à l’origine le bug n’était pas considéré comme de sécurité, et donc aucune mise à jour n’était pushé sur les version “Stable” des distribs en LTS.








KP2 a écrit :



Nan mais laisse tomber… soit tu entres dans la discussion et tu expliques ton point de vue, soit tu cesses de répondre.

Moi aussi aussi je peux dire “Nan !” a chaque fois que je ne suis pas d’accord mais ca n’avance a rien

Ca me fait penser a mes gosses :

“- nan !




  • si !

  • nan !

  • si !

  • nan !

    …”

    Ils peuvent faire ca pendant 15 min d’affilée…





    Il est d’autant plus important de faire cette distinction sur un site généraliste comme tu dis. Autant que un site de spécialistes, on peut mettre ça sous le coup d’un manque de rigueur qui n’empêche pas la compréhension au vu de la supposée maitrise du sujet abordé par les personnes concernées.

    Dans notre cas, c’est limite de l’entretien de la méconnaissance…



    D’autre part, la glibc est loin d’être hégémonique.



    PS. Je ne suis pas là pour défendre tel ou tel chose, je suis d’ailleurs entrain de virer Linux au profit d’un kernel maison. Je disais que je ne m’étalerais pas…









Patch a écrit :



en quoi elle n’est pas stable? c’est une nightly, une testing?







On l’appellerait «Old Stable», c’est une ancienne version stable, autrement dit elle est obsolète quoi…



Dans 10 ans quand elle n’aura plus aucune mise à jour ni rien, on devra toujours l’appeler «stable» ?… <img data-src=" />



Il est clair aussi que si sur le serveur, le service mail tourne sous root (Eh oui, cela se fait par incompétence ou paresse!), point besoin d’élévation de privilèges! Cela, c’est le retour de manivelle de tous les système UNIX et son superutilisateur root, lesquels systèmes pour assumer un niveau tant soit peu “honnête” de sécurité devant être équipés de surcouches de sécurité avec plus ou moins de bonheur!

Pour ceux qui ont connu des systèmes (hélas propriétaires et voués à la mort avant la fin de cette décennie) à sécurité intégrée tels que par exemple VMS, le truc que l’on appelle “informatique” a fait avec la vulgarisation des UNIX et autres Win un retour en arrière de 20 ans au niveau de la sécurité…

Sur de tels systèmes, séparation complète des zones programmes et données, surveillées en permannece par le système… Buffer oveflow impossibles, au premier octet de dépassement d’une zone data, le système éjectait le process. Par ailleurs, impossibilité totale d’exécuter un octet de code dans une zone data, même punition que pour les buffer oveflow… Et ceci sans parler de la gestion des privilères, qui était on ne peut plus “fine”. Pour tous les “gentils pirates”, c’était le purgatoire… Mais hélas, système abandonné, car propriétaire et lié au matériel…

Ce qui est “rigolo” est que désormais, on ne dépend plus du matériel, mais des éditeurs… On a échangé un cheval borgne pour un dromadaire cul de jatte, et on a généré une des plus belles réussite: L’industrie du piratage informatique, et le blanchiment d’argent qui va avec, les trafiquants de drogues devenant petit à petit minoritaires devant cette industrie!


Le problème c’est depuis un moment, NXI ne traite plus uniquement des infos liées à l’informatique justement (d’où le changement de nom)

On peut toujours parler de ligne éditoriale pas claire mais le fait est qu’à force de se disperser, on perd en précision et surtout en valeur ajoutée. De plus l’info arrive de + en + avec du retard je trouve tout en&nbsp; n’apportant pas plus que ce qui a été dit ailleurs&nbsp;&nbsp; :-(








KP2 a écrit :



Nan mais laisse tomber… soit tu entres dans la discussion et tu expliques ton point de vue, soit tu cesses de répondre.

Moi aussi aussi je peux dire “Nan !” a chaque fois que je ne suis pas d’accord mais ca n’avance a rien

Ca me fait penser a mes gosses :

“- nan !




  • si !

  • nan !

  • si !

  • nan !

    …”

    Ils peuvent faire ca pendant 15 min d’affilée…





    Il eut été plus approprié de parler, de mon point de vue, d’une faille de la glibc qui affecterait les systèmes Linux. C’est un poil plus nuancé, mais beaucoup moins racoleur. La langue française est relativement riche, il faut s’en servir…



synology semble être en 2.13… on va espérer qu’ils utilisent jamais ces fonctions.


sur arch, maildrop est en setuid. donc possiblement avec des droits root.


Passez à qmail.








Khalev a écrit :



La version 2.13-38+deb7u6 et vulnérable.



 La 7u7 corrige ces bugs :https://lists.debian.org/debian-security-announce/2015/msg00025.html








Merci <img data-src=">  







Juste une question conne: faire une update, c’est bien. Mais tant qu’on n’a pas redémarré les services qui étaient déjà en train de tourner avant l’update, ceux-ci continuent d’utiliser l’ancienne version de libc6 en cache, right ?



Donc un stop/start des principaux services, voir un reboot (histoire d’être sûr) est nécessaire, non ?

&nbsp;



Au moins en java/net, le compilo te prévient quand tu utilises une fonction @deprecated



(et puis une chaine de caractères n’est pas un bête pointeur sur octets)



<img data-src=" />


2 ans pour patcher?

Quand je pense que certains trouvaient énorme le temps qu’il a fallut à MS pour patcher la divulgation de Google…on les retrouve ici et comme par hasard, tout est normal car le fix est enfin sorti








HenryBasmati a écrit :



Le problème c’est depuis un moment, NXI ne traite plus uniquement des infos liées à l’informatique justement (d’où le changement de nom)

On peut toujours parler de ligne éditoriale pas claire mais le fait est qu’à force de se disperser, on perd en précision et surtout en valeur ajoutée. De plus l’info arrive de + en + avec du retard je trouve tout en&nbsp; n’apportant pas plus que ce qui a été dit ailleurs&nbsp;&nbsp; :-(





Ma foi il y a plusieurs facteurs:




  • Ce sont des être humains qui peuvent faire des erreurs, qui ont des sujets favoris.

  • Il n’ont sûrement pas la science infuse et une equipe de specialiste dans tout les domaines et ne peuvent donc pas forcement traiter tout les sujet avec la même précision/profondeur.

  • Le problème vient aussi peut être du fait que tu attends qu’ils traitent l’information dans le sens que tu veux (biaisé).



As-tu envisagé de lire l’article ? <img data-src=" />








sepas a écrit :



2 ans pour patcher?

Quand je pense que certains trouvaient énorme le temps qu’il a fallut à MS pour patcher la divulgation de Google…on les retrouve ici et comme par hasard, tout est normal car le fix est enfin sorti







A tu lus l’article ou tu viens juste pour troller ?









eliumnick a écrit :



Un nas c’est juste l’utilisation que tu en fais. Tu peux en faire un sous windows si tu veux ^^





Donc un type qui utilise FreeNAS ou DiskStation Manager il est peinard là, non ?



Je suis contre le fait de changer plus de choses que nécessaire à un système pour un problème de glibc.

Il faut juste supprimer la glibc en appliquant le glibc uninstall howto.








127.0.0.1 a écrit :



Au moins en java/net, le compilo te prévient quand tu utilises une fonction @deprecated

<img data-src=" />



En C/C++ aussi… Après si personne ne lit la sortie du compilateur on n’y peut rien.



J’ai lu l’article, mais tu vas m’expliquer que ce n’est pas la même chose.

La faille a été divulguée il y a 2 ans. Certaines distrib l’ont corrigées tout de suite, c’est bien qu’il ont vu le risque. Pourquoi pas les autres?


J’ai lu l’article mais comme d’hab, tu vas m’expliquer que c’est différent blablablabla

On voit juste qu’ils le savent depuis 2 ans et qu’ils n’ont rien fait nada








creatix a écrit :



Ba merde alors apt-get not found <img data-src=" />





Arf… c’est vraiment pas fiable, Debian <img data-src=" />



Pour openSuse ça donne quoi, j’utilise la 12.3 sur mon serveur, j’attendais que mon hébergeur propose l’installation de la 13.1 ou 13.2 avant de migrer pour faire une install propre car en essayant une fois de mettre à jour de la 12.3 à la 13.1 j’ai planté le systéme








Nikodym a écrit :



Il eut été plus approprié de parler, de mon point de vue, d’une faille de la glibc qui affecterait les systèmes Linux. C’est un poil plus nuancé, mais beaucoup moins racoleur. La langue française est relativement riche, il faut s’en servir…





Suffit de lire la news pour le comprendre.&nbsp;

Le français a beau être riche, se limiter au titre d’un article ne permet jamais d’en comprendre les détails.&nbsp;



Ce qui c’est passé c’est :




  • le bug a été identifié et corrigé

  • toutes les distribs sorties après cela incluent la mise à jour

    Normal



    Pour les distribs pros ou à support long, lorsque la version suivante est sortie, les seules mises à jours qui sont poussées dans les dépots sont des mise à jour corrigeant des bugs de sécurité. Or ce bug n’était pas identifié comme étant de sécurité. L’erreur est ici. Depuis que le bug a été requalifié en “bug de sécurité” le patch a été appliqué, et la mise à jour diffusée.








sepas a écrit :



J’ai lu l’article, mais tu vas m’expliquer que ce n’est pas la même chose.

La faille a été divulguée il y a 2 ans. Certaines distrib l’ont corrigées tout de suite, c’est bien qu’il ont vu le risque. Pourquoi pas les autres?





C’est juste écris dans l’article.&nbsp;<img data-src=" />









Konrad a écrit :



On l’appellerait «Old Stable», c’est une ancienne version stable, autrement dit elle est obsolète quoi…



Dans 10 ans quand elle n’aura plus aucune mise à jour ni rien, on devra toujours l’appeler «stable» ?… <img data-src=" />



ou ancienne LTS, comme les précédentes…



Oui j’ai bien compris. Sauf qu’on parle d’un bug qui a été décrit. C’est du code libre, comment Est-ce possible avec les millions de personnes qui lisent ce code que personne n’ait vu qu’il y avait un problème de sécu?

Désolé mais que ce soit du libre ou du proprio, on te décrit un bug, ça met pas longtemps à voir que ça touche la sécu. On parle quand même d’une librairie largement utilisée et les problèmes de sécu par buffer overflow, ça date pas d’hier…

Bref, je ne suis pas là pour troller mais pour vous montrer que oui, ça peut prendre du temps avant de corriger un bug, pour une multitude de raisons différentes.


Qu’attend donc Google pour publier dans le détail l’exploitation de cette faille? on parle d’un truc corrigé en 2013, les 3 mois sont passées là, il faut emmerder aider les services non à jour à s’y mettre.



Ca ne les intéresse pas?<img data-src=" />





&nbsp;







&nbsp;







<img data-src=" />&nbsp;








lincruste_2_la vengeance a écrit :



Donc un type qui utilise FreeNAS ou DiskStation Manager il est peinard là, non ?





Aucune idée ^^



Désolé mais ça a été divulgué il y a 2 ans.

Il suffit qu’une seule personne ait étudié cette remontée il y a 2 ans et en a profité pour faire un exploit, ça fait 2 ans que ça marche.

Maintenant que certains ont considéré que ce n’était pas un bug de sécu, c’est une erreur d’analyses, que certains hacker n’ont peut être pas commis

Tous les OS ont des bugs, sauf que celui-ci a été pointé et non corrigé.

Le fait de le pointer aurait dû amener une correction. Vous nous vendez assez de “C’est du libre, c’est corrigé tout de suite”








sepas a écrit :



Oui j’ai bien compris. Sauf qu’on parle d’un bug qui a été décrit. C’est du code libre, comment Est-ce possible avec les millions de personnes qui lisent ce code que personne n’ait vu qu’il y avait un problème de sécu?

Désolé mais que ce soit du libre ou du proprio, on te décrit un bug, ça met pas longtemps à voir que ça touche la sécu. On parle quand même d’une librairie largement utilisée et les problèmes de sécu par buffer overflow, ça date pas d’hier…

Bref, je ne suis pas là pour troller mais pour vous montrer que oui, ça peut prendre du temps avant de corriger un bug, pour une multitude de raisons différentes.





Ça n’a pas été considéré comme une faille de sécurité. Pourquoi ? Il faudrait voir mais du coup ça n’a pas suivit le processus de diffusion des failles de sécurité. Si tu veux jouer aux comparaisons, à la différence la faille Windows tu remarqueras que la faille a été résolus avant l’annonce de sa découverte.&nbsp;









Patch a écrit :



ou ancienne LTS, comme les précédentes…





La 12.04 lts est toujours maintenue, de même que la version serveur 10.04 lts.



Je ne suis pas sur que les mainteneurs des LTS se tappent tous les rapports de bug. Ils doivent uniquement suivre ceux de sécu. Si l’analyse de base a dit “Pas de sécu”, poubelle. C’est tout. LE fait que le code soit libre, ne veut pas dire qu’il est relu pas des milliard de personne. Surtout sur des libs bas niveau, ou le nombre de personne qui comprennent ce qui se passe doit se limiter aux devs et testeurs.

Erreur humaine qui est passé au travers des maille du processe. Mais la réactivité est là finaliement.








sepas a écrit :



….





Comment prétendre ne pas être un troll quand on a même pas lu l’article ? (ou alors si tu l’as lu, recommence car vraiment tu n’as rien compris)









sepas a écrit :



Désolé mais ça a été divulgué il y a 2 ans.

Il suffit qu’une seule personne ait étudié cette remontée il y a 2 ans et en a profité pour faire un exploit, ça fait 2 ans que ça marche.

Maintenant que certains ont considéré que ce n’était pas un bug de sécu, c’est une erreur d’analyses, que certains hacker n’ont peut être pas commis

Tous les OS ont des bugs, sauf que celui-ci a été pointé et non corrigé.



Le fait de le pointer aurait dû amener une correction. Vous nous vendez assez de "C'est du libre, c'est corrigé tout de suite"







Il y a 2 ans c’est passé comme un bug pas comme faille de sécurité. Il n’y a pas eu de bulletin de sécurité ni d’autre alerte dans ce genre. Du coup la faille n’a été découverte comme faille que récemment et a bien été corrigé rapidement&nbsp; a contrario de windows qui attends la publication pour râler et les fixer ensuite.



C’est du troll volontaire de vouloir interpréter ça comme un manque de de réactivité…



C’est corrigé tout de suite. Mais intégré que lorsque c’est nécessaire, lorsque c’est de sécu sur les versions en cours de support








sepas a écrit :



J’ai lu l’article mais comme d’hab, tu vas m’expliquer que c’est différent blablablabla

On voit juste qu’ils le savent depuis 2 ans et qu’ils n’ont rien fait nada







La faille date de 2000, mais jusqu’à preuve du contraire, personne ne l’avait vue ni n’était au courant.



En 2013 ça a été considéré comme un «bug», ça a été corrigé. Ça n’était pas considéré comme une faille, c’est pour cela que certaines distributions ne se sont pas particulièrement alarmé, et ont fait traîner la mise à jour.



C’est seulement hier (27 janvier) que l’exploit a été révélé, et qu’il est avéré que c’est bien une faille critique. Du coup maintenant toutes les distributions vont se magner de mettre à jour.







We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example.





Donc oui, c’est complètement différent d’un éditeur qui a été prévenu explicitement d’une faille critique, et qui n’a toujours rien fait 3 mois après. Dire qu’il a fallu 2 ans pour corriger la faille, c’est complètement mensonger.









TNZfr a écrit :



Et puis il ne faut pas oublier qu’une grande partie de la libc est compilée dans le noyau en plus du .so pour l’espace utilisateur.





Non. Les libc fond des appels système au noyau mon on ne peut pas dire qu’une libc est compilée dans le noyau.



Il faut bien comprendre que le code n’est quasiment pas relu en dehors de l’équipe en charge de le faire évolué. En réalité, il y a peu de personne dans la “communauté libre” possédant le niveau nécessaire pour détecter et même corriger du code un peu pointu.



C’est comme partout en informatique il y 99% de simple utilisateur.








dgfu6578 a écrit :



Il est clair aussi que si sur le serveur, le service mail tourne sous root (Eh oui, cela se fait par incompétence ou paresse!), point besoin d’élévation de privilèges! Cela, c’est le retour de manivelle de tous les système UNIX et son superutilisateur root, lesquels systèmes pour assumer un niveau tant soit peu “honnête” de sécurité devant être équipés de surcouches de sécurité avec plus ou moins de bonheur!

Pour ceux qui ont connu des systèmes (hélas propriétaires et voués à la mort avant la fin de cette décennie) à sécurité intégrée tels que par exemple VMS, le truc que l’on appelle “informatique” a fait avec la vulgarisation des UNIX et autres Win un retour en arrière de 20 ans au niveau de la sécurité…

Sur de tels systèmes, séparation complète des zones programmes et données, surveillées en permannece par le système… Buffer oveflow impossibles, au premier octet de dépassement d’une zone data, le système éjectait le process. Par ailleurs, impossibilité totale d’exécuter un octet de code dans une zone data, même punition que pour les buffer oveflow… Et ceci sans parler de la gestion des privilères, qui était on ne peut plus “fine”. Pour tous les “gentils pirates”, c’était le purgatoire… Mais hélas, système abandonné, car propriétaire et lié au matériel…

Ce qui est “rigolo” est que désormais, on ne dépend plus du matériel, mais des éditeurs… On a échangé un cheval borgne pour un dromadaire cul de jatte, et on a généré une des plus belles réussite: L’industrie du piratage informatique, et le blanchiment d’argent qui va avec, les trafiquants de drogues devenant petit à petit minoritaires devant cette industrie!







Ouais enfin on y reviens les travaux de MS sur singularity sont là, j’ai commencé à décompiler certaines partie de W10.&nbsp;



Version&nbsp;: 2.19-13 sur ma Debian testing. <img data-src=" />








Konrad a écrit :



&nbsp;



Donc oui, c’est complètement différent d’un éditeur qui a été prévenu explicitement d’une faille critique, et qui n’a toujours rien fait 3 mois après. Dire qu’il a fallu 2 ans pour corriger la faille, c’est complètement mensonger.





Moi ça me semble pas spécialement meilleur, la correction du bug protège de cette faille, il ne s’agit même pas de corriger mais d’appliquer la correction, déjà faite et connue.



Soit y a un truc qui m’échappe dans l’article, soit on peut dire que c’est pas franchement une meilleure attitude…









sepas a écrit :



Oui j’ai bien compris. Sauf qu’on parle d’un bug qui a été décrit. C’est du code libre, comment Est-ce possible avec les millions de personnes qui lisent ce code que personne n’ait vu qu’il y avait un problème de sécu?







Peut-être parce que la détection de failles n’a rien à voir avec la lecture du code source ??? <img data-src=" />









Konrad a écrit :



La faille date de 2000, mais jusqu’à preuve du contraire, personne ne l’avait vue ni n’était au courant.



En 2013 ça a été considéré comme un «bug», ça a été corrigé. Ça n’était pas considéré comme une faille, c’est pour cela que certaines distributions ne se sont pas particulièrement alarmé, et ont fait traîner la mise à jour.



C’est seulement hier (27 janvier) que l’exploit a été révélé, et qu’il est avéré que c’est bien une faille critique. Du coup maintenant toutes les distributions vont se magner de mettre à jour.









Donc oui, c’est complètement différent d’un éditeur qui a été prévenu explicitement d’une faille critique, et qui n’a toujours rien fait 3 mois après. Dire qu’il a fallu 2 ans pour corriger la faille, c’est complètement mensonger.





Quelques corrections.




  • C’est pas que les distributions traînent a mettre a jours, c’est plutôt que les distributions comme Ubuntu 12.04 ne reçoivent plus que des mises a jours de sécurité. Du coup si y’a pas de faille répertoriés ils ne mettent pas a jours.

  • Et de fait les distributions ont envoyé les mises a jours de sécurité avant la divulgation publique du bug.

    <img data-src=" />









after_burner a écrit :



Moi ça me semble pas spécialement meilleur, la correction du bug protège de cette faille, il ne s’agit même pas de corriger mais d’appliquer la correction, déjà faite et connue.



Soit y a un truc qui m’échappe dans l’article, soit on peut dire que c’est pas franchement une meilleure attitude…





La correction du bug corrigeait un bug. Elle n’avait pas été considéré comme une faille de sécurité. Si la mise a jours avait été indiqué y’a 2 ans comme une faille toutes les distrib maintenues auraient publiées à ce moment la.









after_burner a écrit :



Moi ça me semble pas spécialement meilleur, la correction du bug protège de cette faille, il ne s’agit même pas de corriger mais d’appliquer la correction, déjà faite et connue.



Soit y a un truc qui m’échappe dans l’article, soit on peut dire que c’est pas franchement une meilleure attitude…







1- Ce truc a été reconnu comme un «bug» peu important à l’époque. Les vieilles distributions comme Ubuntu 12.04 ne reçoivent plus que des mises à jour de sécurité. Jusqu’à hier, ceci n’en était pas une. Aujourd’hui c’en est une : Ubuntu 12.04 sera patché, de même que les autres distribs vulnérables.



2- Contrairement à un OS propriétaire où tu ne peux rien faire tant que l’éditeur n’a pas mis le patch à disposition, ici le patch était disponible. Les admin système, ou les particuliers chez eux, pouvaient patcher depuis 2013.



3- Quand le bug a été reconnu en 2013, il a été corrigé en très peu de temps. Donc je réitère : dire qu’il a fallu 2 ans pour patcher, c’est mensonger.



Encore une fois, jusqu’à hier personne ne savait que c’était une faille critique, il n’y avait donc pas de raison de s’alarmer ni de forcer la mise à jour sur tous les systèmes.



Comparer ça avec Microsoft qui est prévenu d’une faille critique, et met plus de 3 mois à patcher, c’est complètement à côté de la plaque.



oui il faut redémarrer les services qui utilisent la glibc et sont potentiellement vulnérables (mais en pratique, à part le serveur de mail, Qualys n’a pas réussi à exploiter la faillehttp://www.openwall.com/lists/oss-security/2015/01/27/9 )

Comme la librairie peut être chargée par un très grand nombre de service, y compris ceux ne faisant pas d’appel aux API incriminées, il peut être plus simple de rebooter.

&nbsp;


le piège est actif lorsque Exim cherche à authentifier la source (gethostbyname), bien avant que celui-ci se retrouve dans ta BàL. D’un autre coté, avec sa propension à tout faire sous root, Exim est “coutumier de ce genre d’attaque http://www.gossamer-threads.com/lists/exim/dev/89477)”, d’ou son choix comme cible du proof of concept








seb2411 a écrit :



Il y a 2 ans c’est passé comme un bug pas comme faille de sécurité. Il n’y a pas eu de bulletin de sécurité ni d’autre alerte dans ce genre. Du coup la faille n’a été découverte comme faille que récemment et a bien été corrigé rapidement  a contrario de windows qui attends la publication pour râler et les fixer ensuite.



C’est du troll volontaire de vouloir interpréter ça comme un manque de de réactivité…





Un bug de buffer overflow…Désolé mais en général, ce genre de bug est souvent exploité à des fins malveillantes.

Non, ce n’est pas du troll, loin de là, je trouve juste ça limite qu’une erreur comme celle là puisse arriver.









Konrad a écrit :



La faille date de 2000, mais jusqu’à preuve du contraire, personne ne l’avait vue ni n’était au courant.





Euuu, non !

Dire que jusqu’à preuve du contraire personne n’était au courant de cette faille et ne l’a exploité, c’est stupide. Ça reviendrait à dire que les logiciels close source ne devrait patcher les failles que lorsqu’elles ont été exploitées.



Non, il y a eu une boulette, un billet a été considéré comme un bug alors que c’était une vulnérabilité. La faille était présente depuis les années 2000, le billet a été publié en 2013 et les distribution LTS qu’on trouve le plus dans les entreprises ont été laissées sans patch pendant 2 ans.

Le fait que ça a été classé comme un bug et non comme faille est une fausse excuse. La première faute est faite par ceux qui ont classé le billet, la seconde par les gens qui n’ont pas réagit quand ça s’est produit (à part les boites de cybersécurité, il y a personne dans la communauté pour revoir ce genre de chose ?).

Et le pire, c’est la naïveté de certaines personnes qui pensent qu’aucun hacker ne cherche parmi les rapports de bug afin de voir si certains ne peuvent pas être exploitable, ou ceux pour qui il suffit que la faille n’est pas publiée pour que son exploitation soit totalement improbable.

&nbsp;









sepas a écrit :



Oui j’ai bien compris. Sauf qu’on parle d’un bug qui a été décrit. C’est du code libre, comment Est-ce possible avec les millions de personnes qui lisent ce code que personne n’ait vu qu’il y avait un problème de sécu?

Désolé mais que ce soit du libre ou du proprio, on te décrit un bug, ça met pas longtemps à voir que ça touche la sécu. On parle quand même d’une librairie largement utilisée et les problèmes de sécu par buffer overflow, ça date pas d’hier…

Bref, je ne suis pas là pour troller mais pour vous montrer que oui, ça peut prendre du temps avant de corriger un bug, pour une multitude de raisons différentes.





Bullshit.



Je trouve que c’est un peu facile “nous n’avons pas considéré que c’était de la sécurité”

Pour les prochaines failles, tous les éditeurs auront la réponse toute faite

Je me demande pourquoi Microsoft n’a pas répondu la même chose à Google d’ailleurs


t’as installé Exim sur ton NAS ?


Pour dire ça, évite d’écrire, tu économisera de l’énergie. Tu n’apportes rien








_Beryl_ a écrit :



oui il faut redémarrer les services qui utilisent la glibc et sont potentiellement vulnérables (mais en pratique, à part le serveur de mail, Qualys n’a pas réussi à exploiter la faillehttp://www.openwall.com/lists/oss-security/2015/01/27/9 )

Comme la librairie peut être chargée par un très grand nombre de service, y compris ceux ne faisant pas d’appel aux API incriminées, il peut être plus simple de rebooter.

&nbsp;





Merci <img data-src=" />



Cet argument, je l’ai sorti pleins de fois mais tout le monde me répond que le code est lu par des millions de gens.

Mais je suis d’accord avec toi








seb2411 a écrit :











Konrad a écrit :











Je vois, la faille était considérée comme un bug de la moindre importance mais c’est étonnant que la correction de l’époque empêche son exploitation alors.



Heureusement, le patch existe depuis 2 ans, manquerait plus qu’ils mettent plusieurs semaines avant de le mettre à dispo








sepas a écrit :



Un bug de buffer overflow…Désolé mais en général, ce genre de bug est souvent exploité à des fins malveillantes.

Non, ce n’est pas du troll, loin de là, je trouve juste ça limite qu’une erreur comme celle là puisse arriver.





Oui c’est clairement un erreur de la part des devs de Glib d’avoir laisse passer ca.&nbsp;



Tu peux accepter le risque et ne pas patcher une faille.

&nbsp;MS l’a déjà sorti plusieurs fois à Google, “la vulnérabilité ne vaut pas le coup d’être patchée” !


Donc pour résumer :





  • une faille dans des fonctions « dépréciées ».

  • ces fonctions encore présentes dans de vieilles versions de glibc.

  • ces vieilles versions encore présentes sur de vieux systèmes.










sepas a écrit :



Heureusement, le patch existe depuis 2 ans, manquerait plus qu’ils mettent plusieurs semaines avant de le mettre à dispo





Oui on est pas chez Microsoft. Sinon il auraient attendu 1 mois de plus histoire d’être sur que la faille aura eu le temps d’être exploiter et auraient ensuite accuse des tiers d’être responsable… <img data-src=" />









after_burner a écrit :



Je vois, la faille était considérée comme un bug de la moindre importance mais c’est étonnant que la correction de l’époque empêche son exploitation alors.





En fait le bug et la faille ont la même origine, c’est juste qu’à l’époque de la découverte du bug on avait pas réussi à exploiter le truc, c’est donc resté un bug. Maintenant qu’on a réussi à exploiter le bug, c’est devenu une faille.



Mais résoudre le bug résoud aussi la faille, puisqu’ils ont la même origine.



Oui c’est vrai, quand la faille est quasi impossible à exploiter.

Il y en a une sur le protocole DNS qui a plusieurs années. Quelqu’un a prouvé que c’était faisable mais n’a jamais réussi à la mettre en place.

Le changement est tellement complexe que ça ne sera certainement jamais patché.

Mais là…un buffer overflow, sincèrement…


Ou alors, ils l’auraient corrigée il y a 2 ans <img data-src=" />








sepas a écrit :



Désolé mais ça a été divulgué il y a 2 ans. Il suffit qu’une seule personne ait étudié cette remontée il y a 2 ans et en a profité pour faire un exploit, ça fait 2 ans que ça marche.&nbsp;



&nbsp;

que ça marche sur des installation vieilles de plus de 2 ans, juste mise à jour &nbsp;… &nbsp;sur des services particulier gérés par des serveurs particuliers, par exemple Exim, qui n’est pas le MTA le plus répendu : du coup tu met en évidence que la sécurité c’est aussi la diversité et le choix que propose l’open-source …&nbsp;



Comme effectivement l’open source avait déjà réagi à la découverte du bug (jugé sans importance) et vient de réagir immédiatement lors de sa requalification en en faille de sécurité : toutes les distrib LTS vieilles de plus de 2 ans viennent de voir arriver leur correctif.



C’est sympas de bien souligner que cette réactivité (on est pas obligé d’attendre le mois prochain) ça nous change des mauvais comportement du closed-source.









Mihashi a écrit :



Donc pour résumer :

une faille dans des fonctions « dépréciées ».

ces fonctions encore présentes dans de vieilles versions de glibc.

ces vieilles versions encore présentes sur de vieux systèmes.





Ces vieilles versions présentes sur des systèmes encore supporté par les éditeurs et massivement utilisés en entreprise (car version LTS).



Pas sur. C’était un bug sur des fonctions ‘deprecated’ depuis 10 ans, sans impact sur la sécurité (tel qu’analysé à l’époque). Donc la réaction aurait été: on laisse comme c’est, ça ne fait chier personne, et on économise l’intégration.

&nbsp; MS ne fait pas dans la charité non plus.








sepas a écrit :



Le changement est tellement complexe que ça ne sera certainement jamais patché.

Mais là…un buffer overflow, sincèrement…





Buffer overflow n’est pas forcément synonyme de faille.



Dans mon taff on a souvent des buffers overflow mais ce ne sont que des bugs puisqu’ils sont récupérés plus loin par les systèmes de sécurité. C’est un bug parce que ça change le résultat de la fonction, mais ça ne met pas forcément le système en danger.



Ca c’est ton opinion.

Pour l’histoire le patch tuesday est une demande des entreprises pour pouvoir planifier l’installation des patchs.

Là, on a un patch divulgué dont aucune entreprise n’avait planifié l’installation, donc pour la plupart, elle ne mettront pas à jour avant plusieurs jours (tests, qualif, etc…)


Une faille dans Linux?

Même pas peur&nbsp;<img data-src=" />


Tu veux dire que c’est bien un bug, mais pas une faille, non ?



Rien dit, j’ai mal lu…


Version dont le support n’inclut que les mise à jour de sécurité.

Ce qui a été fait, lorsque le bug est “devenu” de sécurité. Pas de problème.


Merci de l’astuce <img data-src=" />

Pour trouver les commandes/lib utilisant ces fonctions:

&nbsp;find /lib -type f -exec file {} \; | grep ELF | sed ’s/:.*//’ | awk ‘{printf(“objdump -T %s | grep -q gethostby && echo %s\n”, \(1, \)1); }’ | bash -s 2&gt; /dev/null

&nbsp;



Remplacer “find /lib” par “find /bin” voir “find /” tout court !

&nbsp;








Jed08 a écrit :



Euuu, non !

Dire que jusqu’à preuve du contraire personne n’était au courant de cette faille et ne l’a exploité, c’est stupide. Ça reviendrait à dire que les logiciels close source ne devrait patcher les failles que lorsqu’elles ont été exploitées.







Tu as mal compris ce que j’ai voulu dire.



La faille n’a été détectée qu’en 2013. Elle existait dans le code depuis 2000, mais jusqu’ici personne ne l’avait détectée.



Alors oui, peut-être que des hackers l’avaient détectée et exploitée depuis tout ce temps… Mais avec des «peut-être» on ne démontre rien, ce n’est que du FUD. À ce train là je pourrais aussi dire : «peut-être qu’il existe des failles exploitées par des hackers dans tous les OS, WE ARE DOOOOOMED». Ça brasse du vent, ça fait peur, mais ça n’est pas un argument, ça ne démontre rien, ça n’est basé sur rien de concret.



D’où : jusqu’à preuve du contraire, cette faille n’a pas été exploitée, c’est tout ce que j’ai voulu dire. À moins que tu aies des preuves qu’elle ait vraiment été exploitée, dans ce cas on t’écoute…



Et la comparaison que tu fais est fausse. Ce qui est parfois reproché à certains éditeurs de solutions propriétaires, c’est de faire de la sécurité par obscurité : quand ils savent qu’il y a une faille, mais qu’ils espèrent très fort que personne ne la verra, et qu’ils ne patchent pas… Jusqu’au jour où la faille est exploitée.



Ou, comme on l’a vu récemment, un éditeur qui est explicitement prévenu d’une faille, et qui prend plus de 3 mois pour patcher.



Ici ce n’est clairement pas ce qui est arrivé. Si des développeurs s’étaient rendu compte de cette faille avant 2013, ils l’auraient patchée, ils n’auraient pas attendu qu’elle soit exploitée.



Faut-il le répéter : avant hier, ce n’était pas une faille critique…









sepas a écrit :



Ou alors, ils l’auraient corrigée il y a 2 ans <img data-src=" />





Non puisqu’ils patchent après que les failles soient publiques.

&nbsp;&nbsp;









127.0.0.1 a écrit :



Au moins en java/net, le compilo te prévient quand tu utilises une fonction @deprecated



(et puis une chaine de caractères n’est pas un bête pointeur sur octets)



<img data-src=" />





Je me suis laissé dire qu’on va ajouter une fonctionnalité au compilateur C qui vérifie que tu passes bien le bon nombre d’arguments, et qu’ils ont le bon type. Fini les failles où tu passes un entier à une fonction qui attend un char. C’est une révolution ! Ah tiens, il paraît que ça existe depuis 1990&nbsp;<img data-src=" />&nbsp;Plus sérieusement, ce genre de warning existe aussi en C, hein ! Encore faut-il que le développeur en tienne compte.

&nbsp;



CoooolRaoul a écrit :



Dans mes bras! Et même pas besoin sans aller jusqu’au mainframes, suffit de penser aux “minis” des seventies.

Je ne comprend pas non plus comment on peut&nbsp;encore aujourd’hui&nbsp;se traîner ce genre d’anomalie alors que sur des architectures&nbsp;conçues il y a plus d’une quarantaine d’années toute tentative d’exécution de code dans des segments mémoires de type données se terminait irrémédiablement par une exception.





Pareil, pages “NoExecute” sur les processeurs modernes (x86/x64 en tout cas, je suppose que ARM aussi, mais je ne suis pas aussi affirmatif).&nbsp;Encore faut-il écrire des programmes qui se comportent suffisamment bien (pas de code automodifiant…) pour ne pas s’y casser les dents.









CoooolRaoul a écrit :



Dans mes bras! Et même pas besoin sans aller jusqu’au mainframes, suffit de penser aux “minis” des seventies.

Je ne comprend pas non plus comment on peut&nbsp;encore aujourd’hui&nbsp;se traîner ce genre d’anomalie alors que sur des architectures&nbsp;conçues il y a plus d’une quarantaine d’années toute tentative d’exécution de code dans des segments mémoires de type données se terminait irrémédiablement par une exception.





Cela fait un moment que les piles ne sont plus exécutables. Par contre, on parle de retour dans la libc genre un call à system(“/bin/sh”).&nbsp; Et encore, ce genre de fonction doit être protégé par trampoline ou autre pour éviter d’être appelé indirectement. La fonction qui appelle la fonction fautive peut aussi avoir des canaris qui détectent les dépassement de buffer.



Donc, même si il y a encore un problème de buffer overflow, il y a paquet de technique pour les protéger.









eliumnick a écrit :



La 12.04 lts est toujours maintenue, de même que la version serveur 10.04 lts.



ca tombe bien, on parlait de quand ca ne serait plus supoorté.



Lire un résultat de compil quand tu as un code warning ou ok en sortie non mais quoi encore <img data-src=" />

&nbsp;“ça compil ça marche” point final <img data-src=" />








trash54 a écrit :



Lire un résultat de compil quand tu as un code warning ou ok en sortie non mais quoi encore <img data-src=" />

&nbsp;“ça compil ça marche” point final <img data-src=" />





“Compiler c’est livrer, tester c’est douter”&nbsp; <img data-src=" /><img data-src=" /><img data-src=" />



Franchement la rédac,&nbsp; cessez vos&nbsp; gloubi-boulga sur GNU/Linux. Apportez un travail de fond, avec un sous titrage en français pour la vidéo.








sepas a écrit :



Ca c’est ton opinion.&nbsp;





plutôt un fait ;

De plus,&nbsp;quelles sont les fonctions





  • Set user ID root,&nbsp;

  • qui utilisent gethostbyname,&nbsp;

  • en manipulant des données externes

  • présentent sur des serveurs d’entreprises

  • installées il y aplus de 2ans&nbsp;









    sepas a écrit :



    Pour l’histoire le patch tuesday est une demande des entreprises pour pouvoir planifier l’installation des patchs.&nbsp;&nbsp;



    C’est pas paske une majorité des paresseux te demandent de faire une connerie que c’est plus une connerie et qu’il faut la faire.

    &nbsp;







    sepas a écrit :



    Là, on a un patch divulgué dont aucune entreprise n’avait planifié l’installation, donc pour la plupart, elle ne mettront pas à jour avant plusieurs jours (tests, qualif, etc…)&nbsp;



    et bin elle vont faire comme sur les 3 centres de calcule où j’ai un compte : mettre à jour sans délai par précaution &nbsp;:&nbsp;mail reçu ce matin :

    Bonjour,



    &nbsp;Pour des raisons de sécurité, nous devons appliquer un patch de sécurité sur les frontales XXXXXX et de YYYYY dans la matinée.



    &nbsp;Cela&nbsp;entraînera&nbsp;la perte de vos travaux sur les frontales (connexion, transfert de fichiers …) le temps du&nbsp;redémarrage.Veuillez nous excuser de la gène occasionnée.



    et la terre tourne toujours (ceux qui attendaient un résultat lancé il y a plusieurs jours font la gueule)&nbsp;ou&nbsp;évaluer le risque (comme ce n’est pas du loosed source, on a toutes les infos nécessaires pour que les “admin system” justifient de leur salaire) et attendent le “Patch Day” pour l’appliquer …









ZeHiro a écrit :



Version dont le support n’inclut que les mise à jour de sécurité.

Ce qui a été fait, lorsque le bug est “devenu” de sécurité. Pas de problème.





D’où ma question, pourquoi ils ont qualifié ça en tant que bug et pas comme problème de sécu ?



&nbsp;



Konrad a écrit :



Tu as mal compris ce que j’ai voulu dire.



La faille n’a été détectée qu’en 2013. Elle existait dans le code depuis 2000, mais jusqu’ici personne ne l’avait détectée.



Alors oui, peut-être que des hackers l’avaient détectée et exploitée depuis tout ce temps… Mais avec des «peut-être» on ne démontre rien, ce n’est que du FUD. À ce train là je pourrais aussi dire : «peut-être qu’il existe des failles exploitées par des hackers dans tous les OS, WE ARE DOOOOOMED». Ça brasse du vent, ça fait peur, mais ça n’est pas un argument, ça ne démontre rien, ça n’est basé sur rien de concret.



D’où : jusqu’à preuve du contraire, cette faille n’a pas été exploitée, c’est tout ce que j’ai voulu dire. À moins que tu aies des preuves qu’elle ait vraiment été exploitée, dans ce cas on t’écoute…



Et la comparaison que tu fais est fausse. Ce qui est parfois reproché à certains éditeurs de solutions propriétaires, c’est de faire de la sécurité par obscurité : quand ils savent qu’il y a une faille, mais qu’ils espèrent très fort que personne ne la verra, et qu’ils ne patchent pas… Jusqu’au jour où la faille est exploitée.



Ou, comme on l’a vu récemment, un éditeur qui est explicitement prévenu d’une faille, et qui prend plus de 3 mois pour patcher.



Ici ce n’est clairement pas ce qui est arrivé. Si des développeurs s’étaient rendu compte de cette faille avant 2013, ils l’auraient patchée, ils n’auraient pas attendu qu’elle soit exploitée.



Faut-il le répéter : avant hier, ce n’était pas une faille critique…





Pour moi ton raisonnement est mauvais.

Premièrement, ça a toujours été une faille de sécurité. Que personne ne l’ait publiquement publié comme une faille jusqu’à hier, n’enlève rien au fait qu’elle existait.

&nbsp;Ensuite, la sécurité par l’obscurité c’est : on cache le code, comme ça ils pourront pas trouver de failles. Les travers que tu cites existent, sont problématique, mais ce n’est pas de la sécurité par l’obscurité. Or dans ton raisonnement, c’est ce que tu utilises : la faille n’a pas été publiée, donc personne ne peut la trouver ni l’utiliser. En sécurité, parier sur le fait qu’une faille peut ne pas être exploitée pour se rassurer c’est pas le bon moyen.



Après, la faute n’en revient pas aux éditeurs des distributions Linux. Les fautifs sont ceux en charge du support de glibc, et les geeks qui essayent de minimiser la situation en essayant de trouver des excuses.

Oui la faille a été corrigé assez vite après être publiée en tant que telle. Non ce n’est pas normal que la faille soit restée non détectée pendant aussi longtemps.









sepas a écrit :



Pour l’histoire le patch tuesday est une demande des entreprises pour pouvoir planifier l’installation des patchs.







Du coup tous les particuliers sont obligés de suivre ce calendrier, on appréciera la logique de la chose <img data-src=" />



Parce que la première analyse qui en a été faite était erronée, prise sous le mauvaise angle, sans le recul nécessaire… Parce qu’on touche a des libs imbitables par le commun des mortels (voire des devs) et que mesures l’impact d’un bug d’une librairie bas niveau sur l’ensemble d’un système est complexe.

Parce que le mec qui a analysé le bug était fatigué/venait de se faire plaquer/avait la gueule de bois/est un stagiaire…

&nbsp;

&nbsp;








Jed08 a écrit :



Pour moi ton raisonnement est mauvais.

Premièrement, ça a toujours été une faille de sécurité. Que personne ne l’ait publiquement publié comme une faille jusqu’à hier, n’enlève rien au fait qu’elle existait.







Oui, la faille existait, c’est vrai. C’est juste qu’elle n’était pas connue des développeurs de glibc, ni rendue publique.



Pour autant c’est un raccourci futile de prétendre qu’elle a été exploitée par de sombres hackers : rien ne le montre.









Jed08 a écrit :



Ensuite, la sécurité par l’obscurité c’est : on cache le code, comme ça ils pourront pas trouver de failles.







Que le code soit caché (Closed Source) n’a jamais empêché de trouver des failles, ni de les exploiter. La plupart des failles sont trouvées depuis des binaires de toute façon, en analysant ce qui rentre et sort par le réseau par exemple.



Du coup, que le code soit Open Source ne veut pas dire que les failles seront toutes trouvées facilement, hein.









Jed08 a écrit :



Les travers que tu cites existent, sont problématique, mais ce n’est pas de la sécurité par l’obscurité. Or dans ton raisonnement, c’est ce que tu utilises : la faille n’a pas été publiée, donc personne ne peut la trouver ni l’utiliser. En sécurité, parier sur le fait qu’une faille peut ne pas être exploitée pour se rassurer c’est pas le bon moyen.



Après, la faute n’en revient pas aux éditeurs des distributions Linux. Les fautifs sont ceux en charge du support de glibc, et les geeks qui essayent de minimiser la situation en essayant de trouver des excuses.







Aux développeurs de glibc, on peut reprocher de ne pas avoir bien mesuré la portée de ce bug quand ils l’ont découvert en 2013. Pour autant, ils ont patché leur code rapidement, difficile de leur imputer la faute.



Quant aux distributions, de leur point de vue ce n’était pas un bug critique, donc rien d’urgent à patcher. Pour autant, elles auraient dû patcher, ne serait-ce que pour corriger le bug -en faisant cela, sans le savoir elles auraient bouché une faille.









Jed08 a écrit :



Oui la faille a été corrigé assez vite après être publiée en tant que telle.







Non, le bug a été corrigé rapidement en 2013, après avoir été identifié en tant que bug.

Ce n’est que depuis hier que l’on sait que c’est une faille.









Jed08 a écrit :



Non ce n’est pas normal que la faille soit restée non détectée pendant aussi longtemps.







Ce n’est pas la première faille que l’on découvre, qui date de 10 ans ou plus. C’était le cas de Heartbleed, de la faille bash, et de pas mal de failles dans Windows aussi. Nul code n’est infaillible, Closed ou Open Source. Donc je ne sais pas ce que tu entends par «ce n’est pas normal», mais en tout cas ce n’est pas un cas isolé, et on peut parier sur le fait qu’il y en aura d’autres -sous Linux, Windows, Mac OS, Android, ou autre…









Konrad a écrit :



Oui, la faille existait, c’est vrai. C’est juste qu’elle n’était pas connue des développeurs de glibc, ni rendue publique.



Pour autant c’est un raccourci futile de prétendre qu’elle a été exploitée par de sombres hackers : rien ne le montre





Oui mais se dire qu’elle n’a jamais été utilisé auparavant, sans preuves, est aussi naïf.

Des serveurs d’entreprises vulnérables il y en a beaucoup. Des black hat, il y en a beaucoup aussi. Maintenant je ne sais pas comment marche le marché noir sur Internet, mais cela m’étonnerait beaucoup que les failles qui circulent ne soient que des failles déjà publiées et patchées.





Que le code soit caché (Closed Source) n’a jamais empêché de trouver des

failles, ni de les exploiter.

Du coup, que le code soit Open Source ne veut pas dire que les failles seront toutes trouvées facilement, hein.





Ah mais je suis tout à fait d’accord. Je rebondissais juste sur ta phrase qui disait que la sécurité par l’obscurité, c’était ne pas corriger les failles connues dans les logiciels close source.







Aux développeurs de glibc, on peut reprocher de ne pas avoir bien

mesuré la portée de ce bug quand ils l’ont découvert en 2013. Pour

autant, ils ont patché leur code rapidement, difficile de leur imputer

la faute.





Pourtant ils ont leur part de responsabilité. Pour reprendre un exemple qui fâche, si demain MS dit que le bug qu’il a corrigé dans Windows 8.1 et pas dans Windows 7 était en fait une faille de sécurité.

Qu’est ce qu’on dirait ? Que c’était pas de leur faute et qu’ils ont été réactif ? Que de toute façon la faille n’a pas été exploité donc c’est pas grave ?





Quant aux distributions, de leur point de vue ce

n’était pas un bug critique, donc rien d’urgent à patcher. Pour autant,

elles auraient dû patcher, ne serait-ce que pour corriger le bug -en

faisant cela, sans le savoir elles auraient bouché une faille.





Je suis pas d’accord. Les distributions ont tenu leur rôle. Appliquer uniquement les patchs de sécurité.

Après coup c’est facile de dire, ils auraient pu le faire ça aurait corriger la faille. Mais à l’époque rien ne disait que la faille était là et le correctif marchait.

Du coup c’est quoi le message ? Ils devraient patcher tous les bugs des fois que certains soient des failles de sécu ?







Non, le bug a été corrigé rapidement en 2013, après avoir été identifié en tant que bug.

Ce n’est que depuis hier que l’on sait que c’est une faille.





Et depuis hier, les distributions ont été réactives, Debian ayant déjà patché les siennes.





Donc je ne sais pas ce que tu entends par «ce n’est pas

normal»,





Pour moi ce qui n’est pas normal c’est que les mainteneur de glibc se soient trouvés face au problème et se sont dit c’est un bug. Et qu’il a fallut attendre 2 ans que Qualys revienne dire “attention vous avez fait de la merde”









Jed08 a écrit :



Oui mais se dire qu’elle n’a jamais été utilisé auparavant, sans preuves, est aussi naïf.

Des serveurs d’entreprises vulnérables il y en a beaucoup. Des black hat, il y en a beaucoup aussi. Maintenant je ne sais pas comment marche le marché noir sur Internet, mais cela m’étonnerait beaucoup que les failles qui circulent ne soient que des failles déjà publiées et patchées.





Le monde du marché noire et du piratage en tout genre c’est pas une boite noire. Tu peux même acheter des logiciels pour hacker et pirater. Du coup si de tel outils ont été publié pour exploiter cette faille cela se saurait.

Du coup si personne n’est au courant ça réduit fortement les possibilités que la faille puisse avoir été exploité.



Bah tiens, les administrateurs utilisent WSUS alors la planification n’a pas besoin de Microsoft <img data-src=" />

Si un patch de sécurité est prêt à être déployé (attention j’ai pas dit qu’on sautait les phases de test hein) alors il devrait l’être le plus rapidement possible et puis c’est tout…








Jed08 a écrit :



Pour moi ce qui n’est pas normal c’est que les mainteneur de glibc se soient trouvés face au problème et se sont dit c’est un bug. Et qu’il a fallut attendre 2 ans que Qualys revienne dire “attention vous avez fait de la merde”





En même temps tu sais combien de temps il a fallu à Qualys pour trouver le faille?

Si ça se trouve ça leur a pris 2 ans (peu vraisemblable quand même). Tu voudrais que les mainteneurs de glibc passent deux ans à essayer de prouver qu’un bug est une potentielle faille (alors qu’ils n’ont pas forcément les compétences pour)? Parce que dans ce cas là il y a pleins de bugs avec des buffer overflows ou des stack overflows qui ont été corrigés et qui sont restés de simples bugs jusqu’à présent.



Au lieu de critiquer dans le vide ça serait intéressant de savoir ce qu’ont vraiment fait comme tests les dev de glibc à l’époque et la quantité de travail fourni par Qualys, histoire de comparer si c’est un soucis dans les procédures de tests/qualifications de bugs où si c’est juste la faute à pas de chance.



Oui et dans WSUS, tu as une case “valider” avant de passer en prod.

Et cette case, on la coche quand tout à été validé comme son nom l’indique…

Donc une fois que c’est validé, oui c’est très rapide mais c’est la phase d’avant qui est longue et complexe.

Et même quand tu déploies, tu le fais sur un site pilote, et ensuite à grande échelle.

Il faut aussi prendre le cas des clusters où ça doit être ordonnancé, etc…

Donc, non ce n’est pas simple même avec de l’automatisaton


Des paresseux? On ne parle pas de paresse mais d’organisation. tu ne te rends pas comptes des tests de non régressions à faire

Si tu travailles dans une boites ou une coupure est acceptable ok, mais ce n’est pas le cas de tout le monde.

Tu penses que des boites comme Carrefour, Auchan, Norauto, etc… peuvent arrêter les systèmes en plein milieu d’une journée

tu penses qu’en hôpital, on peut tout redémarrer comme ça et ne pas faire de tests de non régression?

Tu penses que tu peux arrêter des chaines dans l’industrie?

Retombe sur terre, tu bosses peut-être dans une boite où ça n’a pas d’impact mais ton cas n’est pas une généralité








Khalev a écrit :



En même temps tu sais combien de temps il a fallu à Qualys pour trouver le faille?







Je remets pas Qualys en cause ici. Ils ont fait leur taf’. Ils ont pas une équipe spécialisé dans la lecture du code de glibc.

&nbsp;



Au lieu de critiquer dans le vide





Je ne critique pas dans le vide. Je dis que Qualys a fait leur boulot, qui aurait pu être éviter si deux ans auparavant les devs de glibc avait mieux fait le leur.



Pour les chaînes dans l’industrie, certains ont pour bonne politique de mettre un minimum d’informatique au niveau contrôle-commande, les automates c’est autrement plus fiable








Jed08 a écrit :



Je remets pas Qualys en cause ici. Ils ont fait leur taf’. Ils ont pas une équipe spécialisé dans la lecture du code de glibc.

 





Je ne critique pas dans le vide. Je dis que Qualys a fait leur boulot, qui aurait pu être éviter si deux ans auparavant les devs de glibc avait mieux fait le leur.





T’as pas compris mon message (et/ou je me suis mal exprimé).

Ce que je veux dire c’est que si ça se trouve ça a pris 2 ans à Qualys et des milliers de cas de fuzzing tous plus complexes les uns que les autres pour trouver la faille, ou alors ils ont utilisé une technique d’exploit qui n’a été découverte qu’il y a 6 mois. À partir de là pourrait-on reprocher aux dev de glibc de ne pas avoir trouvé que c’était une faille il y a 2 ans?



J’imagine que les dev ont leur suite de tests qui leur permet de qualifier si c’est vraiment dangereux et exploitable ou pas (en tout cas c’est comme ça qu’on bosse chez nous). Si le bug passait la suite de test sans déclencher d’alarme, pourrait-on dire que les dev n’ont pas fait leur boulot? Ils ont vu un buffer overflow, ont essayé de l’exploiter avec ce qu’ils connaissaient, n’ont pas réussi, on dit que c’était pas exploitable et basta. Je ne vois pas ce qu’on pourrait leur reprocher de plus ce ne sont “que” des dév au final, pas des experts en sécu.



Après si c’est un gars qui a regardé le bug 5 min et l’a mis en “bug” au lieu de faille sans étudier le truc un poil plus loin oui il y a une erreur. Mais sans plus d’informations c’est difficile de critiquer l’un ou l’autre des acteurs.



Ce qui est clair c’est qu’il y a eu une erreur quelque part, mais la responsabilité n’est pas forcément aisé à trouver. S’ils ont une suite de tests pour tester les bugs, c’est plutôt celui qui a défini la suite de test qui est fautif par exemple puisque la couverture de celle-ci n’est pas suffisante.



Ceci dit si tu as plus d’infos sur les différents protocoles/outils/méthodes par les dévs et Qualys je suis plus que preneur.









Konrad a écrit :



….









Jed08 a écrit :



….





A vous lire on dirait que vous dites la même chose, mais que vous n’arrivez pas à faire comprendre à votre interlocuteur que vous êtes d’accord avec lui. (ou alors jai mal lu :x)









Nikodym a écrit :



Il eut été plus approprié de parler, de mon point de vue, d’une faille de la glibc qui affecterait les systèmes Linux. C’est un poil plus nuancé, mais beaucoup moins racoleur. La langue française est relativement riche, il faut s’en servir…



Tout à fait !



Rappel du titre principal :





Ghost, la nouvelle faille critique qui fait trembler Linux





Deux mots : « nouvelle » qui peut faire sourire , et le présent de « fait », voilà qui ne décrit pas la réalité.



D’ailleurs le sous-titre qui suit infirme le précédent :





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





On comprend que pour les systèmes non mis à jour, les serveurs notamment, ca faille doive être prise au sérieux, mais déjà l’angoisse baisse en intensité, et les conditionnels sont de mise : on semble déjà moins sûr de certaines informations : le copnditionnel est pour les dates ? La gravité ? L’étendue ?



Troisième sous-titre :





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



Ben non, l’immense majorité est mise à jour depuis belle lurette, donc TOUS les systèmes ne sont pas concernés, justement !



JE SAIS que l’article en lui-même n’est pas le vrai sujet, mais le sujet était celui de l’article, désolé.



Et le titre ne correspond pas au niveau de la faille, faire peur fait vendre, décidément, on se croirait en période électorale !

&nbsp;





Si le bug passait la suite de test sans déclencher d’alarme, pourrait-on

dire que les dev n’ont pas fait leur boulot? Ils ont vu un buffer

overflow, ont essayé de l’exploiter avec ce qu’ils connaissaient, n’ont

pas réussi, on dit que c’était pas exploitable et basta. Je ne vois pas

ce qu’on pourrait leur reprocher de plus ce ne sont “que” des dév au

final, pas des experts en sécu.





C’est justement ce cas là que je redoute le plus.

La principale force du libre (selon moi) c’est sa communauté. Mais les mainteneurs ont beau n’être que de devs, il faut pas qu’ils soient des idiots. Ils ont repéré le buffer overflow (en supposant qu’ils ont bien vu qu’ils s’agissent d’un buffer overflow), n’ont pas réussi à l’exploiter et n’ont pas pensé à demander à des vrais experts sécu leur avis sur la question ? Je trouve pas ça sérieux.

Alors si ça se trouve ils n’ont pas repérer le buffer overflow, ont juste trouvé un bug et l’ont corrigé sans savoir ce que c’était car après tout ce ne sont pas des experts sécu.

Ou alors ils ont demandé à des experts sécu leur avis et tout le monde leur ont répondu que c’était rien.


Toi, tu ne connais pas les patchs de sécurité Microsoft qui désactivent partiellement ou totalement une feature. <img data-src=" />


Après “It’s not a bug, it’s a feature”, on a “It’s not a feature, it’s a bug” <img data-src=" />








Jed08 a écrit :



C’est justement ce cas là que je redoute le plus.

La principale force du libre (selon moi) c’est sa communauté. Mais les mainteneurs ont beau n’être que de devs, il faut pas qu’ils soient des idiots. Ils ont repéré le buffer overflow (en supposant qu’ils ont bien vu qu’ils s’agissent d’un buffer overflow), n’ont pas réussi à l’exploiter et n’ont pas pensé à demander à des vrais experts sécu leur avis sur la question ? Je trouve pas ça sérieux.

Alors si ça se trouve ils n’ont pas repérer le buffer overflow, ont juste trouvé un bug et l’ont corrigé sans savoir ce que c’était car après tout ce ne sont pas des experts sécu.

Ou alors ils ont demandé à des experts sécu leur avis et tout le monde leur ont répondu que c’était rien.





Ouai voilà. On est d’accord qu’il y a eu un soucis quelque part, mais sans savoir exactement ce qu’il s’est passé en coulisse, dur dur de savoir. Faudrait retrouver les mailing-lists de l’époque, mais j’ai un peu la flemme pour tout avouer <img data-src=" />





Ghost : la nouvelle faille critique qui fait trembler Linux





C’est amusant cette nouvelle mode qui consiste à donner un petit nom aux failles Linux.



Par contre, je n’ai pas compris pourquoi Linux devrait trembler.



Au passage, la correction d’une faille de sécurité dans un Os est non-événement. Dans tous les OS majeurs, une pléthore de failles et bugs en tous genres sont corrigés régulièrement et même automatiquement. Et pour toute bonne distribution Linux, les mises à jour sont journalières. La plupart des failles sont donc corrigées avant même d’être connues.



Ce qui caractérise le monde du logiciel libre, c’est une plus grande transparence.



Tous les développeurs savent également que des milliers de bugs dormants existent dans TOUS les systèmes d’exploitation. Parce qu’on a pas encore trouvé un seul informaticien sur terre capable de coder sans jamais faire de bugs.



Donc ce qui est important, c’est les patchs de sécurité et la réactivité des développeurs.



A l’occasion, il serait bon de rappeler que les équipements qui ne reçoivent pas de patchs de sécurité régulièrement ne devraient en aucun cas être connectés au réseau. Et c’est valable aussi pour les smartphones.


faut juste savoir comprendre ce que “deprecated” veut dire&nbsp; quand on code … visiblement, on sait pas tous !



<img data-src=" />








psn00ps a écrit :



Toi, tu ne connais pas les patchs de sécurité Microsoft qui désactivent partiellement ou totalement une feature. <img data-src=" />







Bien sur que si… quel est le rapport avec ce que j’ai écris, wsus et le patch tuesday ?



On a surtout une étape “approuver/refuser” sous WSUS qui permet de déployer les updates au parc ou à un groupe d’ordinateur.



Reste que je ne vois toujours pas le besoin d’attendre le patch tuesday et en quoi il est nécessaire pour les admins <img data-src=" />



Si un patch est prêt à être diffuser, il doit l’être sans attendre. Ensuite les admins le déploieront en relation avec leur planning mais ca ce n’est plus le problème de microsoft.


Peut être obsolète mais encore en support et donc majoritairement utilisé en entreprise. Ce n’est pas forcément par incompétence des administrateurs qu’on retrouve encore ces systèmes en prod comme on trouve encore des Windows Vista, 7 et 8.0… L’erreur vient clairement des développeurs de la lib qui n’ont pas considéré que supprimer une API obsolète pouvant entraîner une faille était également une forme de patch de sécurités…


&nbsp;J’avoue que je reste dubitatif devant la vidéo proposée par NXI …



Certes, mon anglais est rudimentaire, mais je trouve que le ‘narrateur’ n’a pas le carisme d’un R.M.S.&nbsp; ou d’un Torvalds pour convaincre son auditoire …



Enfin je dis ça , je dis rien …








sr17 a écrit :



Donc ce qui est important, c’est les patchs de sécurité et la réactivité des développeurs





Une faille qui existerait depuis 2000 et qui aurait été corrigée en 2013 <img data-src=" />



C’est surtout un moyen humain et financier, tout le monde s’en fou de linux c’est donc normal qu’il y ait peu de failles découvertes( ou peut-être que certaines sont connus et utilisés par la nsa ), un linux avec les parts de marchés windows ( bureautique, on s’en fout des serveurs ) et bien les développeurs abandonnent le navire très rapidement !



Les automates sont très souvent reliés à des ERP, c’est même obligatoire quand on travaille en flux tendu, ce qui est la cas de quasi toute industrie aujourd’hui


Pour WSUS, c’est exactement ce que j’ai dis…



Le patch Tuesday a été demandé pour plusieurs raisons:





  • On rassembles les patchs non critiques, pour faire une seule série de validation par mois et pas à chaque patch. La validation coûte extrêmement cher et la mutualiser, c’est un gros avantage!



  • Lorsqu’on sait (sauf cas du O Day) la date à laquelle on patch, ça permet d’organiser les ressources pour pouvoir patcher au plus vite. Sans ce patch tuesday, le patch sort, il faut trouver les ressources pour la qualif, planifier, etc…Autant de temps que les hackers ont pour faire une attaque. Pour toi, possible que c’est facile parce que tu gères une petite infra mais sur des infras de milliers de serveurs et d’apps, ce n’est pas gérable sans prévoir un minimum



  • Cela permet d’organiser le support avec une communication sur les patchs installés et donc de réagir vite le lendemain en cas d’appels au support



  • etc…



    J’ai vu des entreprise où la patching d’un OS (quelqu’il soit) impliquait la coordination de plus de 50 personnes (IT, responsables d’applications, Key users, etc…)

    Donc, si tu es capable de monopoliser tout le monde en claquant des doits, fais attention à ton job car c’est que personne n’a rien à foutre mais ce n’est pas le cas de tout le monde.








Haemy a écrit :



Une faille qui existerait depuis 2000 et qui aurait été corrigée en 2013 <img data-src=" />







Sauf que cela n’a vraiment rien d’extraordinaire. Il n’y a que les profanes pour s’en étonner.



On apprends dans les écoles d’informatique que des milliers de failles peuvent se cacher pendant des années, voir des décennies dans tout logiciel de taille importante.





C’est surtout un moyen humain et financier, tout le monde s’en fou de linux c’est donc normal qu’il y ait peu de failles découvertes( ou peut-être que certaines sont connus et utilisés par la nsa ), un linux avec les parts de marchés windows ( bureautique, on s’en fout des serveurs ) et bien les développeurs abandonnent le navire très rapidement !





Trop gros, passera pas le troll…



Question sécurité, sur Linux, c’est tous les jours qu’on reçoit des patchs…



Et en matière de parts de marché grand public…



http://www.zdnet.fr/actualites/chiffres-cles-le-marche-des-tablettes-par-os-3979…



Et bien entendu, je ne compte pas les box des fai, les routeurs, les télévisions, etc, etc…









Strimy a écrit :



Après “It’s not a bug, it’s a feature”, on a “It’s not a feature, it’s a bug” <img data-src=" />







Adresse Web :

http://postimg.org/image/ym0vgi8ph/



Pour la fonctionnalité, il suffit d’habiller le cafard … <img data-src=" />









sr17 a écrit :



Et en matière de parts de marché grand public…



http://www.zdnet.fr/actualites/chiffres-cles-le-marche-des-tablettes-par-os-3979…







Est-ce que 2015 sera l’année de Windows ? <img data-src=" />



Non, aujourd’hui le matériel est compatible ipv4+6, fonctionne avec ipv4+6 mais n’est pas optimisé et sécurisé pour ipv6. C’est même là le problème. Aujourd’hui, la stack par défaut des serveurs et des clients c’est la stack ipv6. Donc ça peut vite sentir le bonbon si quelqu’un introduit un routeur ipv6 ou même un dad flood dans ton architecture.

&nbsp;


C’est pas pour faire mon troll, mais une faille de 2000, découverte en 2013 (!!!) et toujours pas corrigée chez certains en 2015 (!!!!!!), c’est ça le Libre qui est soit disant mieux que le propriétaire parce que les failles peuvent être découvertes et comblées plus vite ?

C’est bien la preuve qu’il y a un problème : 13 ans pour découvrir la faille alors que le code est ouvert à tout le monde, j’aurais presque envie de dire “mais c’est qui ces branques ?”. Et ne pas corriger une faille après 2 ans, c’est digne de Microsoft&nbsp;<img data-src=" />


Peut-être n’ont-ils pas relu la portion de code correspondante parce qu’ils n’en avaient pas besoin ?&nbsp;On parle d’un truc qui comporte des centaines de milliers de lignes réparties sur des centaines de fichiers.



Et étant donné que cette fonction&nbsp;est&nbsp;classée obsolète depuis des années, c’est encore moins étonnant que personne n’ai relu ce code depuis des lustres.


relis l’article et quelques commentaires.

c’est considéré comme une faille depuis qq jours, c’était classifié seulement comme un bug.








moi1000 a écrit :



C’est pas pour faire mon troll, mais une faille de 2000, découverte en 2013 (!!!) et toujours pas corrigée chez certains en 2015 (!!!!!!), c’est ça le Libre qui est soit disant mieux que le propriétaire parce que les failles peuvent être découvertes et comblées plus vite ?

C’est bien la preuve qu’il y a un problème : 13 ans pour découvrir la faille alors que le code est ouvert à tout le monde, j’aurais presque envie de dire “mais c’est qui ces branques ?”. Et ne pas corriger une faille après 2 ans, c’est digne de Microsoft <img data-src=" />







Bravo ! Tu n’as pas lu l’article, tu n’as pas compris l’histoire, tu n’as pas lu les commentaires, tu n’y connais rien en sécurité, mais tu te permets quand même de l’ouvrir et de faire des comparaisons foireuses ! Mais à part ça tu ne trolles pas bien sûr <img data-src=" />



&nbsp;







sepas a écrit :



Des paresseux? On ne parle pas de paresse mais d’organisation. tu ne te rends pas comptes des tests de non régressions à faire

Si tu travailles dans une boites ou une coupure est acceptable ok, mais ce n’est pas le cas de tout le monde.





Ils l’ont fait au CEA, mais c’est vrai que ça concerne des clusters de guignole (entre autre sur celui ci) …&nbsp;

&nbsp;





sepas a écrit :



tu penses qu’en hôpital, on peut tout redémarrer comme ça et ne pas faire de tests de non régression?





Pour être proche d’un informaticien travaillant dans un hôpital (un CU regional), et vu l’incompétence crasse &nbsp;du DSI et autres RSIs, c’est pas le pire qu’ils ont fait : &nbsp;même si l’équipe informatique ne le souhaite pas, le DSI et les RSIs le peuvent et le font … Alors OUI (je sais ça fait peur, mais ils ont fait pire et pas en 1990 … T’aurais vu la gueule des Urgences réduite au stylo, papier, machine à écrire, et plus de téléphone : ça a fait quelques “dommages collatéraux”)



Bienvenu dans le vrai monde !

&nbsp;

&nbsp;



sepas a écrit :



Des paresseux? On ne parle pas de paresse mais d’organisation. tu ne te rends pas comptes des tests de non régressions à faire … Tu penses que des boites comme Carrefour, Auchan, Norauto, etc… peuvent arrêter les systèmes en plein milieu d’une journée&nbsp;





C’est de la paresse que de faire dépendre la sécurité de SON système d’information d’un tel élément extérieur : cela ne pose aucun problème que de collationner les patchs, et de s’organiser SON propre Patch Day … Mais c’est plus simple de laisser M$ s’en charger : si ça merde, c’est pas la faute au RSI.



PCInpact devrait nous faire un p’it recap des failles critiques par OS histoire qu’on puisse se faire une idée un peu plus subjective <img data-src=" /> un beau camembert comme histogramme sur les 10 dernières années par exemple <img data-src=" />


J’ajouterai heureusement qu’on a pas autant de subjectivité lorsqu’on patch Windows ou MacOS pour des failles critiques <img data-src=" />


On te l’a jamais dit ? La langue pro et management dans le monde est l’anglais. Désolé pour toi si tu te sens pas concerné car tu ne comprends pas..








Cedrix a écrit :



On te l’a jamais dit ? La langue pro et management dans le monde est l’anglais. Désolé pour toi si tu te sens pas concerné car tu ne comprends pas..





Blabla, Seb est mauvais en Anglais incapable de traduire le document video .









pentest a écrit :



Blabla, Seb est mauvais en Anglais incapable de traduire le document video .







Puisque toi tu dois être si bon … vas-y … n’hésite pas !!! <img data-src=" /> <img data-src=" />









moi1000 a écrit :



C’est pas pour faire mon troll, mais une faille de 2000, découverte en 2013 (!!!) et toujours pas corrigée chez certains en 2015 (!!!!!!), c’est ça le Libre qui est soit disant mieux que le propriétaire parce que les failles peuvent être découvertes et comblées plus vite ?

C’est bien la preuve qu’il y a un problème : 13 ans pour découvrir la faille alors que le code est ouvert à tout le monde, j’aurais presque envie de dire “mais c’est qui ces branques ?”. Et ne pas corriger une faille après 2 ans, c’est digne de Microsoft <img data-src=" />







Le problème, c’est que tu sous estime l’ampleur d’un tel projet. On parle de chercher des failles dans un code qui comporte un bon paquet de millions de lignes de code.



C’est un problème de limites humaines vis à vis de la complexité. Car même un excellent informaticien peut passer à côté d’une faille, même en relisant 10 fois le code.



Et personne dans le libre n’a jamais prétendu qu’un code pouvait être exempt de failles.



Voici un petit résumé qui donne des chiffres et les noms de quelques contributeurs. On y trouve même… Microsoft.



http://www.journaldunet.com/developpeur/algo-methodes/le-projet-linux.shtml









bandix400 a écrit :



Ils l’ont fait au CEA, mais c’est vrai que ça concerne des clusters de guignole (entre autre sur celui ci) …





Ca veut rien dire le CEA. Ca dépend de ce qui est hébergé dessus







bandix400 a écrit :



Pour être proche d’un informaticien travaillant dans un hôpital (un CU regional), et vu l’incompétence crasse  du DSI et autres RSIs, c’est pas le pire qu’ils ont fait :  même si l’équipe informatique ne le souhaite pas, le DSI et les RSIs le peuvent et le font … Alors OUI (je sais ça fait peur, mais ils ont fait pire et pas en 1990 … T’aurais vu la gueule des Urgences réduite au stylo, papier, machine à écrire, et plus de téléphone : ça a fait quelques “dommages collatéraux”)



Bienvenu dans le vrai monde !





Non le RSI ou le DSI d’un hôpital n’ont aucun pouvoir. Ce sont les médecins qui l’ont.

Je me suis assez battu sur le sujet pour t’en parler.

Quand tu coupes les scanners, les urgences, etc… même pendant 10mn, crois moi, le RSI refuse tous les patchs suivants







bandix400 a écrit :



C’est de la paresse que de faire dépendre la sécurité de SON système d’information d’un tel élément extérieur : cela ne pose aucun problème que de collationner les patchs, et de s’organiser SON propre Patch Day … Mais c’est plus simple de laisser M$ s’en charger : si ça merde, c’est pas la faute au RSI.





Tu n’as pas compris le principe. Le fait que ça soit géré par MS, ça évite que les patchs soient connu publiquement.

Si ça sortait au jour le jour, et que la planification était géré par chaque entreprise une fois dans le mois, ça laisserait une fenêtre de tir bien plus grande pour les attaques.

Quasi tous les éditeurs veulent copier ce qu’à fait MS, c’est pas pour rien hein



L’information, plus tu la transforme et moins elle est pertinente.








moi1000 a écrit :



C’est pas pour faire mon troll, mais une faille de 2000, découverte en 2013 (!!!) et toujours pas corrigée chez certains en 2015 (!!!!!!), c’est ça le Libre qui est soit disant mieux que le propriétaire parce que les failles peuvent être découvertes et comblées plus vite ?

C’est bien la preuve qu’il y a un problème : 13 ans pour découvrir la faille alors que le code est ouvert à tout le monde, j’aurais presque envie de dire “mais c’est qui ces branques ?”. Et ne pas corriger une faille après 2 ans, c’est digne de Microsoft&nbsp;<img data-src=" />





C’est toi qui as un problème, et depuis plus longtemps que 13 ans…



Est-ce qu’un système sans faille existera un jour ?