« Pourquoi les connexions qui passent par Tor seraient-elles considérées comme fiables ? » m’a demandé un ami qui exploite son propre nœud. J’ai relu deux fois cette annonce, et c’est la couche des adresses qui m’a posé problème. $BNB
Quand un pair se connecte en passant par Tor, le nœud voit l’adresse du processus Tor local, généralement situé sur la même machine ou le même réseau local. La véritable origine du pair distant n’apparaît pas à cette couche. Or l’option non activée par défaut -whitelist accorde un statut « de confiance » en fonction de plages d’adresses IP : dès lors qu’une plage couvre le processus Tor, les connexions extérieures héritent elles aussi de ce statut. Cette option est conçue pour permettre aux clients associés de se connecter au processus Tor local ; le seul critère est l’adresse IP source, pas l’identité de l’autre partie. Une fois la liste blanche activée, les protections contre les attaques par déni de service et les mesures d’atténuation des fuites de confidentialité ne s’appliquent plus du tout à ces connexions. $ETH
Le problème vient de la façon dont les logiciels sont distribués. Plusieurs éditeurs fournissent le logiciel du nœud avec le processus Tor dans un même paquet, et configurent au passage -whitelist avec une plage d’adresses IP correspondante. Certains clients associés ne fonctionnent d’ailleurs qu’avec cette option activée. En combinant les deux, on obtient ce que dit l’annonce originale : « des milliers de nœuds du réseau principal accessibles » ont ajouté toutes les connexions entrantes par Tor à leur liste blanche. Les nœuds qui n’avaient jamais modifié l’option non activée par défaut -whitelist n’ont pas été concernés, même une seule fois. $SOL
Le correctif est assez simple : les connexions entrantes via un onion bind ne sont jamais ajoutées à la liste blanche ; la vérification de correspondance des adresses est tout simplement contournée.
Le changement numéroté 33395 a été publié le 15 septembre 2025, fusionné le 17 septembre, puis rétroporté. Les versions antérieures à 28.3, 29.2 et 30.0 étaient concernées ; seuls les correctifs de version ultérieurs incluent la correction. Auparavant, le 12, Martin Zumsande et Antoine Poinsot avaient signalé le problème à l’équipe de sécurité. Le 17, le même jour, ils en ont également informé Luke Dashjr, le mainteneur de Bitcoin Knots, puis, le 19, plusieurs éditeurs de logiciels concernés. Pour ceux qui ne peuvent pas mettre à niveau immédiatement, l’annonce ne propose qu’une solution temporaire : retirer de -whitelist l’adresse IP du proxy Tor local.
Opinion personnelle, ceci ne constitue pas un conseil en investissement. Vous assumez vos gains comme vos pertes.
#比特币Core披露Tor流量漏洞
Quand un pair se connecte en passant par Tor, le nœud voit l’adresse du processus Tor local, généralement situé sur la même machine ou le même réseau local. La véritable origine du pair distant n’apparaît pas à cette couche. Or l’option non activée par défaut -whitelist accorde un statut « de confiance » en fonction de plages d’adresses IP : dès lors qu’une plage couvre le processus Tor, les connexions extérieures héritent elles aussi de ce statut. Cette option est conçue pour permettre aux clients associés de se connecter au processus Tor local ; le seul critère est l’adresse IP source, pas l’identité de l’autre partie. Une fois la liste blanche activée, les protections contre les attaques par déni de service et les mesures d’atténuation des fuites de confidentialité ne s’appliquent plus du tout à ces connexions. $ETH
Le problème vient de la façon dont les logiciels sont distribués. Plusieurs éditeurs fournissent le logiciel du nœud avec le processus Tor dans un même paquet, et configurent au passage -whitelist avec une plage d’adresses IP correspondante. Certains clients associés ne fonctionnent d’ailleurs qu’avec cette option activée. En combinant les deux, on obtient ce que dit l’annonce originale : « des milliers de nœuds du réseau principal accessibles » ont ajouté toutes les connexions entrantes par Tor à leur liste blanche. Les nœuds qui n’avaient jamais modifié l’option non activée par défaut -whitelist n’ont pas été concernés, même une seule fois. $SOL
Le correctif est assez simple : les connexions entrantes via un onion bind ne sont jamais ajoutées à la liste blanche ; la vérification de correspondance des adresses est tout simplement contournée.
Le changement numéroté 33395 a été publié le 15 septembre 2025, fusionné le 17 septembre, puis rétroporté. Les versions antérieures à 28.3, 29.2 et 30.0 étaient concernées ; seuls les correctifs de version ultérieurs incluent la correction. Auparavant, le 12, Martin Zumsande et Antoine Poinsot avaient signalé le problème à l’équipe de sécurité. Le 17, le même jour, ils en ont également informé Luke Dashjr, le mainteneur de Bitcoin Knots, puis, le 19, plusieurs éditeurs de logiciels concernés. Pour ceux qui ne peuvent pas mettre à niveau immédiatement, l’annonce ne propose qu’une solution temporaire : retirer de -whitelist l’adresse IP du proxy Tor local.
Opinion personnelle, ceci ne constitue pas un conseil en investissement. Vous assumez vos gains comme vos pertes.
#比特币Core披露Tor流量漏洞
