Stéphane Bortzmeyer a écrit 655 commentaires

L'article de Next Inpact dit que « L'idée est ainsi de fournir la solution aux clients des hébergeurs, par exemple pour l'achat d'un nom de domaine. » Étant donné que le principal financier a son propre TLD (hébergé chez Verisign), cette possibilité sera-t-elle pour le .MAIF ou également pour d'autres TLD ?

Leftpad en C est là : https://github.com/lovenunu/leftpad-c

Expliquant ce que Ray Tomlinson avait fait (à part inventer le courrier électronique) : http://mailarchive.ietf.org/arch/msg/ietf/QIvFYGOJTEkPhXqRGsbxbImmEx8

Non, cette histoire de sécurité est largement pipeau http://www.bortzmeyer.org/ipv6-securite.html

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 :

% 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/
Patatras, on a bien la bogue :-( Le serveur affiche :

[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
Et, vu avec tcpdump, cela donne (notez la taille de la réponse UDP, 2569 octets…) :

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

% 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’
C'est parfait, on n'est plus vulnérable.

Si, Serge Julien, dans son commentaire.

Si vous voulez crasher vos logiciels utilisant la vieille libc, voici un service utile :

http://5.150.196.47/

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…

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/

http://www.nextinpact.com/news/97886-ian-murdock-le-ian-debian-est-decede-a-age-42-ans.htm

Mais toujours pas de délégation DNS.

Et qu'est-ce que l'interface de Slack a de si extraordinaire ?

Sinon, j'utilise pidgin et j'en suis content.

"Pas de message privé", dans IRC ??? Je rêve…

Ouais, on peut imaginer tout ce qu'on veut mais la réalité est qu'on n'en sait rien http://www.breitbart.com/tech/2015/12/30/software-pioneer-ian-murdock-dead-after-extraordinary-police-brutality-claims/

Et les gens qui n'ont jamais fait l'objet d'une interpellation policière (surtout aux États-Unis) n'imaginent pas ce que c'est (et les conséquences).

Les tweets en question, sur Web Archive : https://web.archive.org/web/20151229122811/https:/twitter.com/imurdock

Oui, le "deb" de Debian venait de sa compagne (qui n'a pas participé au projet) https://www.debian.org/intro/about#history

Non, IRC aura été remplacé par XMPP :-)

IRC et XMPP sont des protocoles. Ils n'ont pas à être « conviviaux » (c'est le travail du logiciel client) ni à avoir une politique sympa (c'est le travail des gérants du serveur).

Que la propagande des trucs centralisés fermés GAFA comme Slack brouille tout, OK, mais, sur LinuxFr, j'attends plus de sérieux dans la discussion.

Dit comme cela, on dirait du pur baratin marketing. Des tas de gens utilisent IRC, pas uniquement des informaticiens.

https://bits.debian.org/2015/12/mourning-ian-murdock.html

Et comme indiqué plusieurs fois dans la discussion 1) rien à voir avec le DNS ou les noms de domaine, c'est juste un problème avec les règles stupides des AC X.509 et des navigateurs Web 2) il faut mettre netlib.re dans la Public Suffix List.

Mais tu avais bien compris, c'est bien un nom de domaine gratuit. (Il n'y a pas de différence entre domaine et sous-domaine, à part pour la racine, seul domaine à n'être pas sous-domaine.)

Hmmm, la dernière fois que j'ai regardé, le TLD .tk (TLD et pas extension, terme MS-DOS pour les noms de fichiers) ne permettait pas de vraie délégation, le nom pointait forcément vers leurs serveurs HTTP, qui ajoutaient de la pub.

-1 pour la dernière remarque, aggressive et fausse. Tout nom de domaine est aussi un sous-domaine (à part la racine). Donc, nimportequoi.netlib.re est bien un nom de domaine. http://www.bortzmeyer.org/parties-nom-domaine.html (et RFC 7719…)

Il existe plein d'autres noms de domaines gratuits. Le service le plus ancien est eu.org, il est curieux de ne pas l'avoir cité.