Ghost : la nouvelle faille critique qui fait trembler Linux
Ghost in the shell
Le 28 janvier 2015 à 08h15
5 min
Internet
Internet
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.
Ghost : la nouvelle faille critique qui fait trembler Linux
-
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 »
Commentaires (279)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 28/01/2015 à 08h26
Après Windows et Mac OS X ces derniers jours, on a le trio au complet.
Le 28/01/2015 à 08h26
Elle est oppressante la video, avec la tete du mec qui s’avance par a-coup… :)
Le 28/01/2015 à 08h28
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 " />
D’ailleurs il y a une faute dans l’article, la dernière version (stable) de la glibc est 2.20. Signalé :)
Le 28/01/2015 à 08h34
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.
Le 28/01/2015 à 08h34
Linux ? glibc ?
Les articles PCI deviennent de plus en plus approximatifs, pour rester gentil.
Le 28/01/2015 à 08h35
Il faut relativiser un peu la phrase suivante « permettre à des pirates de prendre à distance le contrôle complet
du système, sans avoir la moindre connaissance préalable concernant les
références du système »
Je n’ai vu nulle part mentionner d’élévation de privilège. Bon, on peut faire du dégât quand même, hein, mais pas « prendre le contrôle complet du système ». Ouvrir un shell sur une machine distante, c’est bien et c’est déjà énorme. Pour le contrôle complet, il faut le faire avec des droits root :).
Le 28/01/2015 à 12h35
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.
Le 28/01/2015 à 12h36
Le 28/01/2015 à 12h37
Le 28/01/2015 à 12h37
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
Le 28/01/2015 à 12h38
Le 28/01/2015 à 12h38
Le 28/01/2015 à 12h39
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.
Le 28/01/2015 à 12h43
Le 28/01/2015 à 12h43
Version : 2.19-13 sur ma Debian testing. " />
Le 28/01/2015 à 12h43
Le 28/01/2015 à 12h44
Le 28/01/2015 à 12h45
Le 28/01/2015 à 12h47
Le 28/01/2015 à 12h53
Le 28/01/2015 à 13h00
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.
Le 28/01/2015 à 13h06
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
Le 28/01/2015 à 13h09
Le 28/01/2015 à 13h10
Le 28/01/2015 à 13h11
Le 28/01/2015 à 13h11
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
Le 28/01/2015 à 13h12
t’as installé Exim sur ton NAS ?
Le 28/01/2015 à 13h12
Pour dire ça, évite d’écrire, tu économisera de l’énergie. Tu n’apportes rien
Le 28/01/2015 à 13h13
Le 28/01/2015 à 13h14
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
Le 28/01/2015 à 13h14
Le 28/01/2015 à 13h15
Heureusement, le patch existe depuis 2 ans, manquerait plus qu’ils mettent plusieurs semaines avant de le mettre à dispo
Le 28/01/2015 à 13h17
Le 28/01/2015 à 13h20
Tu peux accepter le risque et ne pas patcher une faille.
MS l’a déjà sorti plusieurs fois à Google, “la vulnérabilité ne vaut pas le coup d’être patchée” !
Le 28/01/2015 à 13h20
Donc pour résumer :
Le 28/01/2015 à 13h20
Le 28/01/2015 à 13h22
Le 28/01/2015 à 13h22
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…
Le 28/01/2015 à 19h28
Le 28/01/2015 à 19h36
Le 28/01/2015 à 20h03
Le 28/01/2015 à 20h40
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.
Le 28/01/2015 à 21h55
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 " />
Le 29/01/2015 à 00h13
Peut-être n’ont-ils pas relu la portion de code correspondante parce qu’ils n’en avaient pas besoin ? 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 est classée obsolète depuis des années, c’est encore moins étonnant que personne n’ai relu ce code depuis des lustres.
Le 29/01/2015 à 01h23
relis l’article et quelques commentaires.
c’est considéré comme une faille depuis qq jours, c’était classifié seulement comme un bug.
Le 29/01/2015 à 09h22
Le 29/01/2015 à 09h53
Le 29/01/2015 à 10h35
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 " /> un beau camembert comme histogramme sur les 10 dernières années par exemple " />
Le 29/01/2015 à 10h37
J’ajouterai heureusement qu’on a pas autant de subjectivité lorsqu’on patch Windows ou MacOS pour des failles critiques " />
Le 29/01/2015 à 11h30
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..
Le 29/01/2015 à 16h07
Le 29/01/2015 à 16h12
Le 29/01/2015 à 18h33
Le 29/01/2015 à 19h23
Le 28/01/2015 à 09h23
Tout dépend du process mémoire qui exécute Ghost. Si c’est un deamon lancé sous compte root, t’as tout gagné.
Le 28/01/2015 à 09h24
Le 28/01/2015 à 09h25
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.
Le 28/01/2015 à 09h25
Le 28/01/2015 à 09h25
Hurd si je ne dis pas de bêtises.
Le 28/01/2015 à 09h25
Oui, la Terre est plate. " />
Le 28/01/2015 à 09h27
libc utilisée par Android
Le 28/01/2015 à 09h27
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.
Le 28/01/2015 à 09h29
Mais euh pas sympa de couper court comme ça à ma question flou " />
note perso : regarder ce soir sur mon OpenSuse si vulnérable ou pas
Le 28/01/2015 à 09h30
Le 28/01/2015 à 09h30
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
Le 28/01/2015 à 09h31
hé ouais… " />
Le 28/01/2015 à 09h32
Le 28/01/2015 à 09h32
Le 28/01/2015 à 09h34
Le 28/01/2015 à 09h34
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…
Le 28/01/2015 à 10h39
Le 28/01/2015 à 10h40
Non, un grand nombre tournent sous linux aussi
Le 28/01/2015 à 10h44
" />
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).
Le 28/01/2015 à 10h45
“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.
Le 28/01/2015 à 10h45
Le 28/01/2015 à 10h47
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/
Et de l’aveu même de Qualys :
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
Donc oui il existe une faille (corrigée depuis 1 an 1⁄2), mais ce n’est pas une raison pour en faire des tonnes…
Le 28/01/2015 à 10h52
Android utilise bionic comme libc, donc non touché.
Le 28/01/2015 à 10h57
Oui bon, bof quoi…
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…
Y aurait beaucoup plus à s’inquiéter " />
Le 28/01/2015 à 10h58
Le 28/01/2015 à 11h01
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…
Le 28/01/2015 à 11h02
Le 28/01/2015 à 11h03
J’avais négocié une réinstall du serveur donc bon ça va accélérer les choses… prochaine distrib ubuntu je pense. Mais je pense pas être le seul coincé avec une vielle version de debian…
Le 28/01/2015 à 11h07
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 !
…”
Ils peuvent faire ca pendant 15 min d’affilée…
Le 28/01/2015 à 11h10
Le 28/01/2015 à 11h12
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…
Le 28/01/2015 à 11h14
Le 28/01/2015 à 08h56
Ah bin merci de l’info, je vais garde ce site au cas où ça m’évitera de passer pour un c ^^”
Le 28/01/2015 à 08h56
C’est surtout que ça rappel l’importance de faire des mises à jour, des paliers “réguliers” sur les infras, …
Le 28/01/2015 à 08h57
Le 28/01/2015 à 08h58
Je suis un utilisateur de Linux. (un peu plus mais on ne va pas s’étaler) " />
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. " />
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 ? " />
Le 28/01/2015 à 08h59
Le 28/01/2015 à 09h00
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…
Le 28/01/2015 à 09h03
Le 28/01/2015 à 09h04
Le 28/01/2015 à 09h04
Le 28/01/2015 à 09h04
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.
Le 28/01/2015 à 09h05
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…
Le 28/01/2015 à 09h06
Le 28/01/2015 à 09h06
Les systèmes basés sur Linux n’utilisent pas tous cette bouse de glibc…
Le 28/01/2015 à 09h09
il y a t il d’autres systèmes que ceux basés sur linux qui peuvent utiliser cette bouse comme tu dis ?
Le 28/01/2015 à 09h10
Le 28/01/2015 à 09h11
Le 28/01/2015 à 09h35
Le 28/01/2015 à 09h35
Le 28/01/2015 à 09h35
J’ai un debian 5 je fait comment? :(
Le 28/01/2015 à 09h37
Le 28/01/2015 à 09h37
comme disait Kahlev, android utilise Bionic , une version allégé de la libc (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 " />
Le 28/01/2015 à 09h38
Le 28/01/2015 à 09h38
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.
Le 28/01/2015 à 09h38
Le 28/01/2015 à 09h38
Le 28/01/2015 à 09h39
Le 28/01/2015 à 09h41
Le 28/01/2015 à 09h41
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…
Le 28/01/2015 à 09h42
Le 28/01/2015 à 09h42
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 ?
Le 28/01/2015 à 09h43
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 µlibc écrit pour android …
Le 28/01/2015 à 09h43
C’est vrai que NXI est clairement un site généraliste " />
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 " />).
Le 28/01/2015 à 09h44
Le 28/01/2015 à 09h44
Le 28/01/2015 à 09h45
Android utilise bionic, pas µClibc.
Grosse différence: bionic ne cherche même pas à être proche de la compatilibilité.
Le 28/01/2015 à 09h45
La version stable actuelle d’Ubuntu c’est la 14.10 … les versions débattues ici sont celles à support étendu.
Le 28/01/2015 à 09h46
Le 28/01/2015 à 09h47
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)
Le 28/01/2015 à 09h50
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.
Le 28/01/2015 à 09h53
Le 28/01/2015 à 09h54
c’est bon cette version n’est pas vulnérable : https://security-tracker.debian.org/tracker/CVE-2015-0235
Le 28/01/2015 à 09h54
Le 28/01/2015 à 09h58
Le 28/01/2015 à 10h01
“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…
Le 28/01/2015 à 10h03
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…
Le 28/01/2015 à 10h03
Euuuh, j’aime beaucoup le “on évite de laisser des fichiers exécutables setuid”. " />
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 !
Le 28/01/2015 à 10h04
Le 28/01/2015 à 10h05
Le 28/01/2015 à 10h07
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… " />
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.
Le 28/01/2015 à 10h08
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 28/01/2015 à 10h10
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…
Le 28/01/2015 à 10h12
Le 28/01/2015 à 10h13
Le 28/01/2015 à 10h21
Avec un système à jour (y compris sur la glibc), on ne risque rien à propos de cette faille 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 28/01/2015 à 10h21
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 ! " />
Le 28/01/2015 à 10h22
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”
Le 28/01/2015 à 10h22
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 > moins de consommation > 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… " />
Le 28/01/2015 à 10h23
Rsync pour la suppression est plus rapide
Le 28/01/2015 à 10h24
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 :)
Le 28/01/2015 à 10h24
Le 28/01/2015 à 10h24
effectivement, ma mémoire m’a joué un tours; c’est bien Bionic …
Le 28/01/2015 à 10h27
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 " />
Le 28/01/2015 à 11h22
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.
Le 28/01/2015 à 11h26
Le 28/01/2015 à 11h26
Le 28/01/2015 à 11h30
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 28/01/2015 à 11h33
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 n’apportant pas plus que ce qui a été dit ailleurs :-(
Le 28/01/2015 à 11h34
Le 28/01/2015 à 11h35
synology semble être en 2.13… on va espérer qu’ils utilisent jamais ces fonctions.
Le 28/01/2015 à 11h36
sur arch, maildrop est en setuid. donc possiblement avec des droits root.
Le 28/01/2015 à 11h38
Passez à qmail.
Le 28/01/2015 à 11h39
Le 28/01/2015 à 11h40
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)
" />
Le 28/01/2015 à 11h43
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
Le 28/01/2015 à 11h46
Le 28/01/2015 à 11h46
As-tu envisagé de lire l’article ? " />
Le 28/01/2015 à 11h47
Le 28/01/2015 à 11h51
Le 28/01/2015 à 15h46
Le 28/01/2015 à 15h51
Le 28/01/2015 à 15h53
Le 28/01/2015 à 15h55
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.
Le 28/01/2015 à 16h35
Toi, tu ne connais pas les patchs de sécurité Microsoft qui désactivent partiellement ou totalement une feature. " />
Le 28/01/2015 à 16h51
Après “It’s not a bug, it’s a feature”, on a “It’s not a feature, it’s a bug” " />
Le 28/01/2015 à 17h13
Le 28/01/2015 à 17h14
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.
Le 28/01/2015 à 17h20
faut juste savoir comprendre ce que “deprecated” veut dire quand on code … visiblement, on sait pas tous !
" />
Le 28/01/2015 à 17h24
Le 28/01/2015 à 17h29
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 " />
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.
Le 28/01/2015 à 17h45
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…
Le 28/01/2015 à 18h19
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. ou d’un Torvalds pour convaincre son auditoire …
Enfin je dis ça , je dis rien …
Le 28/01/2015 à 18h28
Le 28/01/2015 à 19h03
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
Le 28/01/2015 à 19h14
Pour WSUS, c’est exactement ce que j’ai dis…
Le patch Tuesday a été demandé pour plusieurs raisons:
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.
Le 28/01/2015 à 09h14
Le 28/01/2015 à 09h15
Le 28/01/2015 à 09h15
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”…
Le 28/01/2015 à 09h16
Je me pose plusieurs questions:
Le 28/01/2015 à 09h16
Ç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.
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.
Le 28/01/2015 à 09h16
Donc en gros il faut avoir un serveur de mail fonctionnel sur sa machine ?
Le 28/01/2015 à 09h16
Le 28/01/2015 à 09h17
Le 28/01/2015 à 09h17
pied dans le plat on :
Android c’est sur une base linux et c’est touché ou pas ?
pied dans le plat off
Le 28/01/2015 à 09h19
Le 28/01/2015 à 09h20
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.
Le 28/01/2015 à 09h21
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.
Le 28/01/2015 à 09h21
Le 28/01/2015 à 09h22
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! " /> ). 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é.
Le 28/01/2015 à 09h22
Le 28/01/2015 à 09h23
“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.
Le 28/01/2015 à 12h06
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.
Le 28/01/2015 à 12h08
Le 28/01/2015 à 12h09
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?
Le 28/01/2015 à 12h10
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
Le 28/01/2015 à 12h13
Le 28/01/2015 à 12h14
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
Le 28/01/2015 à 12h14
Le 28/01/2015 à 12h15
Ce qui c’est passé c’est :
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.
Le 28/01/2015 à 12h15
Le 28/01/2015 à 12h24
Le 28/01/2015 à 12h29
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.
Le 28/01/2015 à 12h31
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?" />
" />
Le 28/01/2015 à 12h32
Le 28/01/2015 à 12h32
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”
Le 28/01/2015 à 12h34
Le 28/01/2015 à 12h34
Le 28/01/2015 à 13h48
Le 28/01/2015 à 13h51
Franchement la rédac, cessez vos gloubi-boulga sur GNU/Linux. Apportez un travail de fond, avec un sous titrage en français pour la vidéo.
Le 28/01/2015 à 13h54
Le 28/01/2015 à 13h57
Le 28/01/2015 à 13h57
Le 28/01/2015 à 14h04
Heureusement , je carbure au BSD
Le 28/01/2015 à 14h08
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…
Le 28/01/2015 à 14h09
Le 28/01/2015 à 14h24
Le 28/01/2015 à 14h33
Le 28/01/2015 à 14h34
Bah tiens, les administrateurs utilisent WSUS alors la planification n’a pas besoin de Microsoft " />
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…
Le 28/01/2015 à 14h51
Le 28/01/2015 à 15h16
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
Le 28/01/2015 à 15h32
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é
Le 28/01/2015 à 15h32
Le 28/01/2015 à 15h39
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
Le 30/01/2015 à 06h28
L’information, plus tu la transforme et moins elle est pertinente.
Le 30/01/2015 à 14h51
Le 30/01/2015 à 16h13
Est-ce qu’un système sans faille existera un jour ?
Le 28/01/2015 à 08h36
En plus, ça vient donner des leçons sur l’histoire de VLC. " />
Le 28/01/2015 à 08h36
Correctif dispo depuis hier pour Debian.
Le 28/01/2015 à 08h36
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 ?
Le 28/01/2015 à 08h37
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! " /> ). 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!
Le 28/01/2015 à 08h44
Le 28/01/2015 à 08h45
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
Le 28/01/2015 à 08h45
Le 28/01/2015 à 08h49
Pour ma part je suis en 2.13-38+deb7u7 sur la mienne et il ne me propose pas de maj :‘( (ou alors j’ai rien compris " />)
Le 28/01/2015 à 08h51
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).
Le 28/01/2015 à 08h51
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… " />
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.
Le 28/01/2015 à 08h54
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.
Le 28/01/2015 à 08h54
Le 28/01/2015 à 08h54
Tu as la version qui a été déployée hier pour colmater la faille. " />
https://security-tracker.debian.org/tracker/CVE-2015-0235
Le 28/01/2015 à 08h55
Le 28/01/2015 à 08h55
Le 28/01/2015 à 08h55
Le 28/01/2015 à 10h28
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 :)
Le 28/01/2015 à 10h28
Le 28/01/2015 à 10h29
Le 28/01/2015 à 10h29
Le 28/01/2015 à 10h29
Sur les NAS ? Mais ils sont pas tous basés sur BSD ?
Le 28/01/2015 à 10h30
Le 28/01/2015 à 10h31
" />
C’est exactement ça et bien sûr je faisais de l’humour
Mais depuis qu’on fait de la logique stateless à la place de la statefull on n’arrète pas d’avoir des failles
le vieil adage de “la confiance n’exclut pas le controle” 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
" />
Le 28/01/2015 à 10h33
Le 28/01/2015 à 10h33
emacs > all.
Le 28/01/2015 à 10h35
Le 28/01/2015 à 10h35
Bah en plus de GNU Linux, ça peut probablement toucher GNU Hurd.
Le 28/01/2015 à 10h35
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.
Le 28/01/2015 à 10h37
Le 28/01/2015 à 10h38
Le 28/01/2015 à 10h38
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…
Le 28/01/2015 à 10h38
emacs > Linux
Le 28/01/2015 à 13h23
Ou alors, ils l’auraient corrigée il y a 2 ans " />
Le 28/01/2015 à 13h25
Le 28/01/2015 à 13h27
Le 28/01/2015 à 13h29
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.
MS ne fait pas dans la charité non plus.
Le 28/01/2015 à 13h29
Le 28/01/2015 à 13h30
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…)
Le 28/01/2015 à 13h30
Une faille dans Linux?
Même pas peur " />
Le 28/01/2015 à 13h30
Tu veux dire que c’est bien un bug, mais pas une faille, non ?
Rien dit, j’ai mal lu…
Le 28/01/2015 à 13h31
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.
Le 28/01/2015 à 13h31
Merci de l’astuce " />
Pour trouver les commandes/lib utilisant ces fonctions:
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> /dev/null
Remplacer “find /lib” par “find /bin” voir “find /” tout court !
Le 28/01/2015 à 13h35
Le 28/01/2015 à 13h38
Le 28/01/2015 à 13h38
Le 28/01/2015 à 13h42
Le 28/01/2015 à 13h43
Le 28/01/2015 à 13h45
Lire un résultat de compil quand tu as un code warning ou ok en sortie non mais quoi encore " />
“ça compil ça marche” point final " />