Une faille très sérieuse (CVE-2015-7547) vient d'être découverte dans la GNU libc (qui équipe tous les serveurs et desktops utilisant Linux…). Lorsqu'on résoud un nom en adresse, avec getaddrinfo(), le tampon où arrive la réponse n'est pas toujours le bon, et une réponse de grande taille peut écraser la mémoire, et mener au crash du client, voire à l'exécution de code (aïe).
Une exploitation typique est : le méchant se connecte à un serveur SMTP GNU/Linux depuis une adresse IP dont il contrôle in-addr.arpa et/ou ip6.arpa (les domaines qui servent aux résolutions d'adresses IP en noms). Le serveur SMTP fait des requêtes DNS (PTR puis A et AAAA). La réponse (contrôlée par l'attaquant) est de grande taille et paf (le chien).
Il est donc essentiel de mettre à jour tout de suite.
À noter que l'équipe de la glibc donne des conseils stupides (limiter la taille des réponses DNS, par exemple dans un pare-feu, débrayer IPv6 et/ou DNSSEC dans les applications) qui ramèneraient quinze ans en arrière.
- Article de synthèse par les découvreurs de la faille (Google) https://googleonlinesecurity.blogspot.de/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
- Synthèse par les gens de la glibc, avec les conseils idiots que je citais https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
- Rapport de bogue glibc https://sourceware.org/bugzilla/show_bug.cgi?id=18665
- Il existe une exploitation (crash seulement, pas d'exécution de code) https://github.com/fjserna/CVE-2015-7547
- Les patches chez Debian http://www.debian.org/security/2016/dsa-3481
# Euh....
Posté par LaBienPensanceMaTuer . Évalué à 10.
Ca n'a rien de stupide, au contraire.
Si tu as un parc de 800 serveurs à mettre à jour, ce genre de limitations que tu peux mettre en place en amont peut t'éviter de te faire trouer en attendant que tu fasses l'update de tes machines… car, pour peu que tu sois sur des OS un peu customisé, la mise à jour de libc peut être cause de suée …
[^] # Re: Euh....
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Débrancher les machines marcherait aussi… Ces conseils stupides vont avoir des conséquences : plus de connexion IPv6, plus de sécurité (en coupant DNSSEC et en limitant la taille).
Donc, oui, c'est stupide et il est regrettable que des publications comme Hacker News http://thehackernews.com/2016/02/glibc-linux-flaw.html aient repris ce conseil de manière acritique.
Par ailleurs, si on a un parc de 800 machines, et aucun mécanisme pour les mettre à jour, on est de toute façon mal parti…
[^] # Re: Euh....
Posté par fox (site web personnel) . Évalué à 8.
Je pense que ce serait une erreur d'appliquer ces recommandations a la lettre et pour tous les cas existants, tout autant qu'il serait stupide de les rejeter en bloc.
Nous n'avons pas tous les memes cas d'usage. Entre Mr Michu (oui, madame delegue a son mari parfois) qui a son serveur perso sur internet (ben oui, il a decouvert Linux, c'est cool, mais le firewall j'ai rien compris, alors j'ai ouvert tous les ports sur ma CoincoinBOX) et des fermes de serveurs critiques niveau business accessibles sur Internet il faut je pense faire la part des choses.
[^] # Re: Euh....
Posté par Moonz . Évalué à 2.
J’aimerais qu’on m’explique un jour les raisons derrière ce fétichisme de « il faut fermer tous les ports même s’il y a rien qui écoute derrière ».
Sur mon VPS perso j’ai 0 ports fermés et j’ai du mal à voir où est le problème.
[^] # Re: Euh....
Posté par fox (site web personnel) . Évalué à 1.
Sur un serveur tu installes tout et n'importe quoi comme une grande partie des gens ont tendance a le faire sur un desktop ?
[^] # Re: Euh....
Posté par Moonz . Évalué à 3.
Justement non, je fais gaffe à ce que j’installe, du coup je ne me retrouve pas avec des services inconnus qui écoutent sur des ports dont je n’ai pas besoin. Les ports ouverts sont ceux dont j’ai besoin, les autres sont fermés pour la bonne et simple raison que personne n’écoute derrière, pas par un firewall dont je ne vois pas l’utilité.
[^] # Re: Euh....
Posté par Mimoza . Évalué à 10.
Imagine que un attaquant arrive a exécuter un code sur ton serveur qui lance un programme communiquant avec l'extérieur. Avec un parefeu ou tous les ports sont bloqué le programme n'aura qu'une portée très limité voir nulle, avec tous les port ouvert il n'aura aucun mal a faire ses méfaits …
Exemple concret une faille d'un site web permet a un pirate de lancer un relai de spam, avec un pare-feu restrictif = 0 spam envoyé, si ouvert = Bannissement de tes IP même pour ton serveur de mail légitime.
[^] # Re: Euh....
Posté par LaBienPensanceMaTuer . Évalué à 8.
Tout à fait …
Je rajouterai que, si l'on veut bien faire, il faut filtrer en entrée ET en sortie.
Perso, au boulot, j'administre une infra un peu critique (hébergement de code très sensible sous NDA qui, s'il fuitait, nous exposerait à des lourdes poursuites) et je filtre même l'HTTP en sortie.
Car en admettant que tu filtres les ports en écoute, les pirates ont la parade avec les shellcode qui font du connect back … donc il faut tout filtrer.
Encore une fois, il faut bien garder en tête que la sécurité à appliquer à un système doit rester fonction des données à protéger…
[^] # Re: Euh....
Posté par Hobgoblins Master (Mastodon) . Évalué à 10.
Prophylaxie, défense en profondeur, même si tu gère bien ton serveur, tu n’est pas à l’abri d’une mise à jour ou lors d’une installation d’avoir une appli qui écoute sur un port non prévu. Si tu te fait trouer une appli sans élévation de privilège, ça évite de rendre des services non désirés.
Une fois le pare feux en place, ça permet facilement de virer les « méchants » (fail2ban, snort/suricata + ipset…).
Ça à pour effet de bord de ralentir les scanners de ports (DROP plutôt qu’un ICMP port unreachable), donc c’est bénéfique pour tout le monde ☺
[^] # Re: Euh....
Posté par nono14 (site web personnel) . Évalué à 3.
+1
Tu bloques une éventuelle backdoor via le firewall qui rend inacessible celle ci sur le serveur web par exemple.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: Euh....
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Personne n’a suggéré de simplement désinstaller la glibc ?
Les trolls, c’est plus ce que c’était…
[^] # Re: Euh....
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Si, Serge Julien, dans son commentaire.
[^] # Re: Euh....
Posté par KiKouN . Évalué à 5.
J'ai essayé mais mon clavier s'est blo
# Dans la presse généraliste
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Un mauvais article de la BBC (la grande majorité des objets, de l'embarqué, n'utilise pas la glibc) http://www.bbc.com/news/technology-35592916 et un autre d'Ars Technica (qui reprend les mauvais conseils des mainteneurs de la glibc) http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
# IPv6
Posté par Hobgoblins Master (Mastodon) . Évalué à 5.
D’après, le rapport de bogue pointé, la désactivation d’IPv6 (à quelque niveau que ce soit, OS, résolveur cache…) ne fait pas partie des solutions applicables, ça n’empêchera pas les applications (donc la libc) de faire des requêtes de type AF_UNSPEC (donc demander en // un A et un AAAA), l’exploit pouvant se trouver dans la réponse A, même s’il n’y a pas de réponse AAAA.
# Pour tester
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Si vous voulez crasher vos logiciels utilisant la vieille libc, voici un service utile :
http://5.150.196.47/
# Pour parer au plus pressé…
Posté par Serge Julien . Évalué à 8.
Il y a toujours la solution expliquée ici ;-)
# Debian
Posté par X345 . Évalué à 10.
Pour information, la mise à jour est passée dans Debian stable et sid. Les versions de la glibc qui contiennent la correction de bug, et donc qui ne sont pas affectées par la vulnérabilité sont les suivantes:
Stable: 2.19-18+deb8u3
Sid: 2.21-8
Vous pouvez utiliser
dpkg -l libc-bin
pour vérifier quelle version tourne sur votre système. Pensez également à relancer les serveurs/services qui utilisent la libc (donc tous, hein). C'est bien joli d'avoir une version à jour sur le disque, si elle est pas chargée en mémoire et utilisée ça sert à rien. Si possible, rebootez même, vu le tas de trucs qui utilisent la libc, c'est probablement l'option la plus safe.Sinon, vous pouvez utiliser
lsof | grep 'libc-'
pour voir la liste des process qui utilisent l'ancienne libc :systemd 1 root DEL REG 8,2 24382311 /lib/x86_64-linux-gnu/libc-2.19.so
systemd-j 140 root DEL REG 8,2 24379415 /lib/x86_64-linux-gnu/libc-2.19.so
atd 311 daemon DEL REG 8,2 24379415 /lib/x86_64-linux-gnu/libc-2.19.so
cron 312 root DEL REG 8,2 24379415 /lib/x86_64-linux-gnu/libc-2.19.so
ntpd 320 root DEL REG 8,2 24379415 /lib/x86_64-linux-gnu/libc-2.19.so
[...]
exim4 26832 Debian-exim DEL REG 8,2 24382311 /lib/x86_64-linux-gnu/libc-2.19.so
sshd 29321 fabien mem REG 8,2 1738176 24379470 /lib/x86_64-linux-gnu/libc-2.19.so
bash 29322 fabien mem REG 8,2 1738176 24379470 /lib/x86_64-linux-gnu/libc-2.19.so
openvpn 29691 nobody mem REG 8,2 1738176 24379470 /lib/x86_64-linux-gnu/libc-2.19.so
Sur cette machine, on peut voir que
sshd
,openvpn
etbash
utilisent la nouvelle version, mais quesystemd
,exim4
,atd
oucron
utilisent l'ancienne version (fichierDEL
donc supprimmé sur le disque), et donc qu'il faut les relancer.Debian testing (Strech) est toujours vulnérable à cette heure.
[^] # Re: Debian
Posté par Boa Treize (site web personnel) . Évalué à 4.
C'est également disponible sur Ubuntu depuis hier soir (au moins sur 14.04 LTS).
[^] # Re: Debian
Posté par KiKouN . Évalué à 5.
Ha, systemd utilise encore la libc.
[^] # Re: Debian
Posté par X345 . Évalué à 10.
Cher camarade, je vous rappelle que nous ne sommes pas encore Vendredi. Merci de votre compréhension.
[^] # Re: Debian
Posté par KiKouN . Évalué à 4.
Désolé, je suis complétement décalé, j'ai pris mon lundi.
[^] # Re: Debian
Posté par Olivier (site web personnel) . Évalué à 4.
Merci pour l'astuce du lsof !
Ce soir à 20h, Strech est lui aussi patché :
[^] # Re: Debian
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
Voir aussi checkrestart (paquet debian-goodies) et needrestart (backports pour stable), pour savoir quoi redémarrer après une mise à jour.
# Test de l'exploitation
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Voici ce que donne l'exploitation "officielle" https://github.com/fjserna/CVE-2015-7547 sur une Debian "sid" (alias "unstable").
On git clone le code et on lance le serveur DNS méchant (il faut être root car il écoute sur le port privilégié 53) :
% sudo python CVE-2015-7547-poc.py
On modifie le /etc/resolv.conf pour utiliser ce résolveur DNS ("nameserver 127.0.0.1"). On teste :
Patatras, on a bien la bogue :-( Le serveur affiche :% wget http://rue89.com/
--2016-02-17 15:59:53-- http://rue89.com/
Resolving rue89.com (rue89.com)... zsh: segmentation fault wget http://rue89.com/
Et, vu avec tcpdump, cela donne (notez la taille de la réponse UDP, 2569 octets…) :[UDP] Total Data len recv 27
[UDP] Total Data len recv 27
Connected with 127.0.0.1:60873
[TCP] Total Data len recv 58
[TCP] Request1 len recv 27
[TCP] Request2 len recv 27
Maintenant, on patche (remettre un résolveur qui marche, puis "aptitude update && aptitude dist-upgrade" puis remettre le résolveur méchant dans resolv.conf). Et on réeessaie :16:49:27.565275 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 69: 127.0.0.1.40012 > 127.0.0.1.53: 50702+ A? rue89.com. (27)
16:49:27.565306 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 69: 127.0.0.1.40012 > 127.0.0.1.53: 1856+ AAAA? rue89.com. (27)
16:49:27.575962 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 2569: 127.0.0.1.53 > 127.0.0.1.40012: 1856| 0/0/0 (2527)
16:49:27.576263 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 74: 127.0.0.1.45586 > 127.0.0.1.53: Flags [S], seq 1826763891, win 43690, options [mss 65495,sackOK,TS val 1657736187 ecr 0,nop,wscale 7], length 0
C'est parfait, on n'est plus vulnérable.% wget http://rue89.com/
--2016-02-17 18:12:27-- http://rue89.com/
Resolving rue89.com (rue89.com)... failed: Name or service not known.
wget: unable to resolve host address ‘rue89.com’
[^] # Re: Test de l'exploitation
Posté par Vincent . Évalué à 2.
Attention, le client CVE-2015-7547-client.c fourni par le dépôt https://github.com/fjserna/CVE-2015-7547 ne fonctionne pas chez moi sur Jessie, alors que ton test avec wget oui.
Il fonctionne sur Squeeze et Wheezy.
J'ai également fait une version de CVE-2015-7547-client.c où l'on passe le serveur DNS en argument et qui peut être intégré à Ansible ou autre outil de gestion de serveur: https://github.com/Toubib/CVE-2015-7547/blob/master/CVE-2015-7547-client.c, mais comme le test n'est pas fonctionnel sur toutes les versions de Debian je me méfie un peu …
# Slackware non vulnérable
Posté par Ellendhel (site web personnel) . Évalué à 8.
Curieusement, Slackware ne semble pas être vulnérable au problème, du fait d'un patch spécifique appliqué aux sources de glibc :
discussion et détails sur le forum LinuxQuestions.
Explications de Patrick Volkerding, mainteneur de la distribution :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.