Linux

Webex 46.8.0.35631 sur Fedora 44 reste derrière une bannière jaune affichant « Offline - No internet connection » alors que tous les autres programmes de la machine atteignent internet sans se plaindre. Ça a coupé la ligne VoIP net. Le réseau n’a jamais été le problème : Cisco livre son propre fork d’OpenSSL et l’a compilé avec OPENSSLDIR pointant sur /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, un répertoire qui existe sur un conteneur de build et nulle part ailleurs, donc il ne charge aucune ancre de confiance et toute poignée de main échoue. L’article se déroule dans l’ordre : ce qu’est vraiment l’état cassé, demander à la bibliothèque livrée où elle croit que vivent ses certificats, reproduire le code d’erreur exact hors de Webex, pourquoi rien ne vous prévient, les deux correctifs qui ne marchent pas et pourquoi, et celui qui marche. Puis le processus de build : ils ont utilisé $ORIGIN pour le code et laissé trois chemins de données absolus, l’en-tête du RPM nomme un identifiant de conteneur, donc le conteneur était déjà dans la chaîne et n’a jamais servi à exécuter le résultat, le paquet exige une glibc de 2018 parce qu’ils refusent de lier statiquement, 2,2 Go sont livrés deux fois, et il ne porte aucune documentation ni aucun fichier marqué comme configuration. Puis comment il aurait fallu le construire, les six correctifs et le contrôle d’une ligne qui l’attrape. Et enfin le recoupement : Cisco détient 98 entrées au catalogue des vulnérabilités activement exploitées de la CISA, derrière Microsoft seulement, et un chemin de confiance que personne n’a vérifié et un contournement que personne n’a vérifié sont la même faute à des enjeux différents.

Un VPN, c’est deux tâches : quelque chose qui fabrique un lien virtuel, et quelque chose qui transporte les octets. PPP fait la première depuis 1994 et se moque de la seconde — c’est pourquoi PPTP, L2TP et chaque ligne commutée que vous avez utilisée sont le même protocole sur des transporteurs différents. Netcat est un transporteur. Ce billet le construit des deux façons. D’abord pppd : l’option pty et ce qu’elle fait d’un pseudo-terminal, la version TCP que tout le monde essaie d’abord, pourquoi faire tourner un protocole de flux dans TCP s’effondre sous la perte, la version UDP qu’il faut prendre, le tramage HDLC asynchrone et l’ACCM qui décide de la bande passante dépensée à échapper des caractères de contrôle, l’adressage et le routage et IPV6CP, et garder le lien en vie quand le transporteur meurt sans le dire. Puis le même tunnel sans PPP du tout — un tap, un datagramme par trame sur UDP, le préfixe de longueur qu’il faut inventer soi-même sur TCP, tun contre tap, et le bridging. Puis la partie pour laquelle netcat n’a pas de réponse : envelopper le transporteur dans TLS avec ncat, stunnel et openssl, et dans DTLS avec socat, qui est la forme qu’on veut vraiment. Ce n’est jamais vraiment le bon outil, et c’est là le propos : il montre comment se comporte l’egress dès qu’un attaquant a root dans votre réseau et que l’accès sortant n’était pas bloqué par défaut, et pourquoi le default-deny à la frontière est le seul contrôle qui ait jamais été réel.

Ping, pas le reste de l’ICMP, est le risque : l’écho est un canal auquel chaque hôte doit répondre avec vos propres octets, si bien qu’un réseau qui « n’autorise que le ping » a déjà un VPN complet vers l’extérieur. On parcourt d’abord la menace — ce qu’elle coûte à votre sortie, et comment un visiteur sur votre WiFi ou une prise ethernet non verrouillée peut en ouvrir un — puis trois tunnels qui marchent, bâtis sur le seul ping (Hans, icmptunnel, et un court en Python avec AES-128), les pièges du MTU et de l’IPv6, et la règle qui le ferme : jeter l’écho, garder les erreurs, sur nftables, pf, Cisco, Junos, MikroTik et Windows.

« Le port 445 est bloqué quelque part » n’est pas un diagnostic, et c’est pour ça que les tickets pare-feu rebondissent entre vous et votre opérateur pendant une semaine. Chaque routeur du chemin vous doit un ICMP Time Exceeded quand votre budget de sauts est épuisé, et ça transforme un délai d’attente en une distance. J’ai fait monter le TTL sur ma propre ligne et j’ai trouvé trois défauts que je ne me connaissais pas : un blocage SMB à onze sauts, des resets SMTP forgés à un saut, et une règle IPv4 sans jumelle IPv6.