Ethereum: Bösartige Transaktion lässt alle geth-Knoten abstürzen

Veröffentlicht am 19. September 2016 von Christoph Bergmann // 3 Kommentare

Nodes, Miner, Pools – eine Transaktion mit Schadcode knockt alle Knoten mit dem beliebten geth-Client aus. Die Hashrate von Ethereum stürzt um 20 Prozent ab, Panik breitet sich aus, ob dies nun die Killer-Transaktion ist, die das Ethereum-Netzwerk vernichtet. Doch die Situation scheint unter Kontrolle zu sein.

Nicht nur das Recht, sondern auch die Sprache ist derzeit noch nicht in der Lage, mit allen Aspekten rund um Kryptowährungen umzugehen. Wie nennt man beispielsweise eine Transaktion, die einen bösartigen Code beinhaltet? Und wie einen Vertrag, der diesen Code ausführt? Mal-Transaction? Schad-Vertrag?

Egal wie man es nennt – mit der turing-vollständigen Ethereum-Blockchain ist diese Art von bösartigem Code in die Welt getreten. Wenn man (fast) alles per Transaktion auf eine Blockchain schicken kann, gibt es auch (fast) unendlich viele Wege, dies auszunutzen. Nachdem bereits der DAO-Unfall gezeigt hat, dass Verträge, die nur aus Code bestehen, auch gehackt werden können, wiederholt sich nun das Spiel. Zumindest für all diejenigen, die gestern Abend einen Knoten der beliebten Go-Implementierung geth laufen hatten.

Um etwa 20 Uhr am Sonntag-Abend stürzten reihenweise die geth-Nodes ab, weil der Arbeitsspeicher ausging. Die Miner, die geth benutzten, stoppten, die pools, die auf geth liefen, fuhren herunter. Die Hashrate von Ethereum fiel um 20 Prozent, und die Ethereum-Foundation gab eine recht faktenarme Warnung heraus, die alle geth-Nodes mit “hoher Wahrscheinlichkeit” einen “schweren” Absturz prophezeite. Leise Panik breitete sich aus.

War war geschehen? Anders als gewöhnliche Hacks, findet ein Hack der Ethereum-Blockchain quasi “live” vor aller Augen statt. Ausgelöst wurde der Crash von Block #2283416. Recht schnell identifizierten die Entwickler eine verdächtige Transaktion in diesem Block, die im Payload-Feld ein Stückchen Code sowie die Nachricht “Fahrt nach Hause” beinhaltete. Im selben Block gibt es jedoch noch eine weitere 0-Eth-Transaktion mit einem sehr hohen Gas-Limit, die einen “From Shanghai with Love” betitelten Vertrag auslöst, der Operationen ausführt, die von Entwicklern als “ziemlich verrückt” bezeichnet werden. Ein wenig lustig ist der Vertragstitel, weil die Ethereum-Entwickler derzeit in Shanghai auf der Devon2 sind, der größten Ethereum-Messe der Welt. Der Zeitpunkt hätte also nicht “besser” sei können.

Der Angriff demonstrierte, wie wichtig es ist, mehrere Node-Implementierungen zu haben. Während die Bitcoin-Knoten so gut wie ausschließlich auf C++ fährt, gibt es von Ethereum Client-Software in verschiedenen Sprachen. Neben geth, das in Go geschrieben ist, sind etwa Implementierungen für Ruby, Python oder Java und Rust verfügbar. Bis gestern Abend war geth der mit Abstand dominante Client, der 80-90 Prozent aller Knoten abdeckte. Dementsprechend verheerend traf der Angriff das Netzwerk.

Für den Rust-Client Parity, der als besonders schnell und leicht gilt, war der Angriff hingegen so etwas wie ein Glücksfall. Denn Parity war nicht betroffen und arbeitete stabil weiter. Die Mining-Pools haben daher den Client gewechselt, neu synchronisiert (was mit Parity relativ schnell geht) und den Betrieb wieder aufgenommen. Wer Mist benutzt, kann ebenfalls einfach Parity installieren, mit dem Befehl “parity –geth” starten und dann Mist wie gewohnt starten.

Die Geth-Entwickler, haben sich derweil in Shanghai zusammengesetzt, den Bug gesucht, gefunden, ausgemerzt, ein update von geth geschrieben und veröffentlicht. Die Anzahl der Nodes steigt wieder, die Hashrate ist wieder auf dem alten Stand, der Preis, der sowieso nur sehr kurz und sehr seicht eingebrochen ist, ist schon wieder höher als er vorher war, und all das geschah innerhalb weniger Stunden. Alles gut also?

Zumindest sieht es derzeit so aus, als gehe von dem Bug und der Transaktion keine unmittelbare Gefahr mehr aus. Der Vorfall zeigt jedoch, dass noch längst nicht alle Bugs und Angriffe entdeckt sind, die eine turing-vollständige Blockchain wie Ethereum bedrohen. Er zeigt auch, dass derselbe Angriff verheerende Folgen gehabt hätte, wenn der Bug in mehreren Implementierungen enthalten wäre.