XRP-„Zehn-Jahre-Schwachstelle“ sorgt für Schlagzeilen: Der Patch ist bereits verfügbar – entscheidend sind diese drei zeitlichen Unterschiede
„XRP aus dem Nichts erzeugen“ klingt nach einem Vorfall, der gerade stattfindet. Stellen wir zunächst die Zeitangaben richtig: Öffentlich bekannt gemacht wurde die Schwachstelle am 9. Oktober; die Korrektur für die Zahlungs-Engine war bereits zuvor mit xrpld 3.4.1 veröffentlicht worden. Am 10. Oktober wurden dann auf GitHub der Quellcode dieser Version und die Upgrade-Hinweise veröffentlicht. Offenlegung, Softwarekorrektur und Aktivierung der Mainnet-Regeln beantworten jeweils unterschiedliche Fragen.
Erstens: Die Schwachstelle in der Zahlungs-Engine betraf Version 3.4.0 und ältere Versionen. Ein Forscher meldete sie am 22. September über das Bug-Bounty-Programm. Nachdem das Team den Fehler reproduziert hatte, stufte es dessen Schweregrad höher ein; am 25. September wurde eine Korrektur veröffentlicht. Die offizielle Untersuchung geht davon aus, dass das Problem auf Code aus dem Jahr 2015 zurückzuführen sein könnte. Dem Bericht zufolge wurden keine Belege dafür gefunden, dass das öffentliche Netzwerk ausgenutzt wurde. Das ist eine Schlussfolgerung der Untersuchung und lässt sich weder dahin gehend ausweiten, dass für sämtliche Aktivitäten in der Vergangenheit zweifelsfrei keine Auffälligkeiten belegt seien, noch als direkter Beleg für einen Angriff mit unautorisierter Ausgabe zusätzlicher XRP darstellen.
Zweitens: Derselbe Bericht behandelt auch ein Problem bei der Validierung interner Batch-Transaktionen. Als diese Regel entdeckt wurde, war sie im Mainnet noch nicht aktiviert. Die Software enthielt die Korrektur bereits; fixBatchV1_2 wurde jedoch erst am 9. Oktober im Mainnet aktiviert. Die Korrektur der Zahlungs-Engine trat dagegen unmittelbar mit dem Node-Upgrade in Kraft. Wer diese beiden Korrekturpfade zu der Aussage vermischt, „erst am 9. Oktober seien alle Schwachstellen geschlossen worden“, stellt das Zeitfenster des Risikos falsch dar.
Drittens: Die Einschätzung für gewöhnliche XRP-Inhaber und Node-Betreiber darf nicht vermischt werden. GitHub fordert Server derzeit zum Upgrade auf Version 3.4.1 auf. Das bedeutet, dass ältere Versionen durch neue Amendments blockiert wurden und nicht mehr normal synchronisieren können. Die Upgrade-Anforderung betrifft die Serversoftware; sie bedeutet nicht, dass XRP-Inhaber ihre Vermögenswerte auf eine unbekannte Website übertragen müssen, um ihre „Wallet zu reparieren“. Bei Links, die unter dem Vorwand einer Sicherheitsmeldung nach der Seed-Phrase fragen oder zur Autorisierung auffordern, sollte man zuerst die offiziellen Kanäle überprüfen.
Was ich aus diesem Vorfall mitnehme: Sicherheitsvorkehrungen sollten nicht immer wieder auf derselben Annahme beruhen. Wenn bei der Zahlungsberechnung ein Fehler vorliegt, kann auch die Prüfschicht ihn übersehen, falls sie dieselben mathematischen Annahmen verwendet. Deshalb lohnt es sich, sowohl den Patch als auch die anschließenden Überprüfungsverfahren weiterzuverfolgen. Diese Schlussfolgerung ergibt sich aus dem Offenlegungsprozess und ist keine Aussage über Schwachstellen in anderen Protokollen.
Ich werde weiter beobachten, ob die offiziellen Stellen die Untersuchungsergebnisse ergänzen, wie weit die Upgrades älterer Nodes fortgeschritten sind und welche Sicherheitsüberprüfungen anschließend stattfinden. Diese Punkte können die Einschätzung des technischen Risikos verändern. Ob der Preis weiter steigt, lässt sich dagegen nur anhand von Belegen zu Handelsaktivität und Nachfrage beurteilen. Eine behobene Sicherheitslücke allein ist kein Kaufsignal.
Quellen: Offizielle XRPL-Veröffentlichung zur Schwachstelle vom 9. Oktober; Release Notes zu XRPLF/rippled 3.4.1. Überprüft am 10. Oktober um 22:36 Uhr Pekinger Zeit.
„XRP aus dem Nichts erzeugen“ klingt nach einem Vorfall, der gerade stattfindet. Stellen wir zunächst die Zeitangaben richtig: Öffentlich bekannt gemacht wurde die Schwachstelle am 9. Oktober; die Korrektur für die Zahlungs-Engine war bereits zuvor mit xrpld 3.4.1 veröffentlicht worden. Am 10. Oktober wurden dann auf GitHub der Quellcode dieser Version und die Upgrade-Hinweise veröffentlicht. Offenlegung, Softwarekorrektur und Aktivierung der Mainnet-Regeln beantworten jeweils unterschiedliche Fragen.
Erstens: Die Schwachstelle in der Zahlungs-Engine betraf Version 3.4.0 und ältere Versionen. Ein Forscher meldete sie am 22. September über das Bug-Bounty-Programm. Nachdem das Team den Fehler reproduziert hatte, stufte es dessen Schweregrad höher ein; am 25. September wurde eine Korrektur veröffentlicht. Die offizielle Untersuchung geht davon aus, dass das Problem auf Code aus dem Jahr 2015 zurückzuführen sein könnte. Dem Bericht zufolge wurden keine Belege dafür gefunden, dass das öffentliche Netzwerk ausgenutzt wurde. Das ist eine Schlussfolgerung der Untersuchung und lässt sich weder dahin gehend ausweiten, dass für sämtliche Aktivitäten in der Vergangenheit zweifelsfrei keine Auffälligkeiten belegt seien, noch als direkter Beleg für einen Angriff mit unautorisierter Ausgabe zusätzlicher XRP darstellen.
Zweitens: Derselbe Bericht behandelt auch ein Problem bei der Validierung interner Batch-Transaktionen. Als diese Regel entdeckt wurde, war sie im Mainnet noch nicht aktiviert. Die Software enthielt die Korrektur bereits; fixBatchV1_2 wurde jedoch erst am 9. Oktober im Mainnet aktiviert. Die Korrektur der Zahlungs-Engine trat dagegen unmittelbar mit dem Node-Upgrade in Kraft. Wer diese beiden Korrekturpfade zu der Aussage vermischt, „erst am 9. Oktober seien alle Schwachstellen geschlossen worden“, stellt das Zeitfenster des Risikos falsch dar.
Drittens: Die Einschätzung für gewöhnliche XRP-Inhaber und Node-Betreiber darf nicht vermischt werden. GitHub fordert Server derzeit zum Upgrade auf Version 3.4.1 auf. Das bedeutet, dass ältere Versionen durch neue Amendments blockiert wurden und nicht mehr normal synchronisieren können. Die Upgrade-Anforderung betrifft die Serversoftware; sie bedeutet nicht, dass XRP-Inhaber ihre Vermögenswerte auf eine unbekannte Website übertragen müssen, um ihre „Wallet zu reparieren“. Bei Links, die unter dem Vorwand einer Sicherheitsmeldung nach der Seed-Phrase fragen oder zur Autorisierung auffordern, sollte man zuerst die offiziellen Kanäle überprüfen.
Was ich aus diesem Vorfall mitnehme: Sicherheitsvorkehrungen sollten nicht immer wieder auf derselben Annahme beruhen. Wenn bei der Zahlungsberechnung ein Fehler vorliegt, kann auch die Prüfschicht ihn übersehen, falls sie dieselben mathematischen Annahmen verwendet. Deshalb lohnt es sich, sowohl den Patch als auch die anschließenden Überprüfungsverfahren weiterzuverfolgen. Diese Schlussfolgerung ergibt sich aus dem Offenlegungsprozess und ist keine Aussage über Schwachstellen in anderen Protokollen.
Ich werde weiter beobachten, ob die offiziellen Stellen die Untersuchungsergebnisse ergänzen, wie weit die Upgrades älterer Nodes fortgeschritten sind und welche Sicherheitsüberprüfungen anschließend stattfinden. Diese Punkte können die Einschätzung des technischen Risikos verändern. Ob der Preis weiter steigt, lässt sich dagegen nur anhand von Belegen zu Handelsaktivität und Nachfrage beurteilen. Eine behobene Sicherheitslücke allein ist kein Kaufsignal.
Quellen: Offizielle XRPL-Veröffentlichung zur Schwachstelle vom 9. Oktober; Release Notes zu XRPLF/rippled 3.4.1. Überprüft am 10. Oktober um 22:36 Uhr Pekinger Zeit.