Das Entwicklungsteam von Bitcoin Core teilte am 12. Juni auf X mit, dass die im neuen Bitcoin-Core-31.0-Version eingeführte Funktion -privatebroadcast eine Datenschutzlücke aufweist: Unter bestimmten Netzwerkbedingungen wird bei einem fehlgeschlagenen v2-Handshake eine Verbindung zu Peer-Knoten über IPv4 oder IPv6 hergestellt, wodurch dem Empfänger die öffentliche IP-Adresse des Absenders offengelegt wird.
Betroffene Nutzerbedingungen: fünf Voraussetzungen müssen gleichzeitig erfüllt sein
Laut dem offiziellen Bitcoin-Core-Update wird der Knoten nur dann von dieser Schwachstelle betroffen, wenn alle folgenden fünf Bedingungen gleichzeitig erfüllt sind:
· Der Knoten läuft mit Bitcoin Core 31.0 und die Funktion -privatebroadcast ist aktiviert
· Die Übertragung erfolgt per RPC-Befehl sendrawtransaction (Wallet-RPCs wie sendtoaddress, sendall usw. verwenden kein privates Broadcasting, daher sind sie nicht betroffen)
Tor kann ausgehende Verbindungen herstellen
· Eine direkte ausgehende IPv4- oder IPv6-Verbindung ist möglich (ohne -onlynet-Einschränkung und ohne -proxy=...-Konfiguration)
· Die BIP324-v2-Übertragung ist nicht deaktiviert (keine Einstellung -v2transport=0)
Verbindungen zu Onion- und I2P-Peers sind nicht betroffen, weil sie bei jedem v1-Retry stets über ihre jeweiligen Proxy-Routen laufen.
Technischer Mechanismus der Schwachstelle: v2-Handshake fehlgeschlagen, dann v1-Retry ohne Tor
Laut offizieller Erklärung wird die Schwachstelle ausgelöst, wenn der private Broadcasting-Auswahlmechanismus Peers unterstützt, die v2 (BIP324)-Transport nutzen, und diese Peers über IPv4 oder IPv6 erreichbar sind. In der Anfangsverbindung verläuft die Verbindung wie erwartet über die Tor-Proxy-Route. Wenn der v2-Handshake fehlschlägt, versucht Bitcoin Core stattdessen, mit dem v1-Protokoll erneut zu verbinden; dieses v1-Retry läuft nicht über den Tor-Proxy, sondern direkt über IPv4 oder IPv6 und gibt dadurch die IP-Adresse des Auslösers preis.
Dieses Verhalten verstößt gegen die Datenschutzgarantie, die in der 31.0-Version beschrieben ist: „Der Empfänger wird niemals ihre IP-Adresse (sowie ihren geografischen Standort) kennen.“ Das Entwicklungsteam bestätigt, dass diese Schwachstelle höchstwahrscheinlich dadurch absichtlich ausgelöst wird, dass ein bösartiger Peer den v2-Handshake gezielt abschaltet und so ein erzwungenes v1-Retry provoziert.
Drei vorübergehende Lösungen: bis zur Veröffentlichung von 31.1 nutzbar
Bitcoin Core stellt folgende drei vorübergehende Lösungen bereit:
Lösung 1 (empfohlen): Deaktivieren Sie -privatebroadcast direkt durch die Einstellung -privatebroadcast=0
Lösung 2: Deaktivieren Sie den v2-Transport per Einstellung -v2transport=0. Hinweis: Diese Einstellung führt dazu, dass alle Verbindungen des Knotens das unverschlüsselte v1-Protokoll verwenden, wodurch Knoten im öffentlichen Netz leichter zu identifizieren (Fingerprinting) und stärkerer Überwachung ausgesetzt sein können.
Lösung 3: Leiten Sie ausgehenden IPv4/IPv6-Verkehr über Tor, indem Sie -proxy=127.0.0.1:9050 setzen (entsprechend dem tatsächlichen Tor-SOCKS-Port ersetzen). Hinweis: Diese Einstellung macht den Knoten anfälliger für Sybil-Angriffe.
Häufige Fragen
Sind Knoten betroffen, die Wallet-RPCs wie sendtoaddress oder sendall verwenden?
Laut dem offiziellen Bitcoin-Core-Update verwenden Wallet-RPCs (z. B. sendtoaddress, sendall usw.) keine private Broadcasting-Funktion. Daher sind sie nicht von dieser Schwachstelle betroffen. Die Schwachstelle wird nur dann ausgelöst, wenn über sendrawtransaction gebroadcastet wird und die übrigen vier Bedingungen erfüllt sind.
Tritt diese Schwachstelle auch ohne bösartige Knoten natürlich auf?
Laut offizieller Erklärung ist es für tatsächlich v2-Transport unterstützende Peers unter normalen Umständen unwahrscheinlich, dass der v2-Handshake fehlschlägt. Am wahrscheinlichsten wird die Schwachstelle dadurch absichtlich ausgelöst, dass ein bösartiger Peer den v2-Handshake gezielt abschaltet, um ein v1-Retry zu erzwingen.
Wie sieht der Veröffentlichungskalender für Bitcoin Core 31.1 aus?
Laut dem offiziellen Bitcoin-Core-Update wird die Reparaturlösung mit der Version 31.1 veröffentlicht, aber die Mitteilung enthält keine konkreten Angaben zum Veröffentlichungstermin. Offiziell wird empfohlen, vor dem Upgrade auf 31.1 eine der oben genannten drei vorübergehenden Lösungen zu verwenden.
