Ethereum-Entwickler entdeckten einen Fehler, der dazu führen konnte, dass EVM-Ketten aufgrund eines Überschussgas-Fehlers im Besu-Client stecken blieben.
Ethereum-Entwickler haben einen Fehler im Besu-Ethereum-Client entdeckt, der zu einem „Konsensversagen in Netzwerken mit mehreren EVM-Implementierungen“ führen kann.
Gary Schulte meldete das Problem an das Hyperledger GitHub Repository und wurde von Martin Holst Swende gefunden. Es wird davon ausgegangen, dass „keine Produktionsnetzwerke Transaktionen haben, die diesen Fehler auslösen würden“.
Bug, der bei der Code-Überprüfung von The Merge identifiziert wurde
Swende dokumentierte, dass er den Fehler während „einiger TheMerge“ fand. Als Antwort aufunseren Journalisten erklärte Swende, dass Benutzer, die einen Besu-Knoten betreiben, stecken geblieben wären und „nicht in der Lage waren, der Kanonenkette zu folgen.“ Außerdem hätte jedes „Besu-dominierte Netzwerk in seinen Bahnen gestoppt werden können. „
Sie wären stecken geblieben und hätten der Kanon-Kette nicht folgen können. Und/oder, jedes besu-dominierte Netzwerk (nicht-eth-mainnet) hätte in seinen Bahnen gestoppt werden können.
– M H (((Swende))) (@mhswende) September 27, 2022
Der Besu-Client ist nach Geth der zweitbeliebteste Client im Ethereum-Netzwerk. Laut Daten von ethernodes.org wird der Besu-Client von 7,81 % der Ethereum-Mainnet-Clients verwendet.
Anfällige Besu-Client-Versionen
Version 22.7.1 des Besu-Clients enthält einen Fix, der sicherstellt, dass „überschüssiges Gas nicht für innere Transaktionsaufrufe allokiert wird, und der die Fehler mit überschüssigem Gas korrigiert.“
Versionen vor 22.1.3 werden ebenfalls „eine fehlerhafte Ausführung verhindern“, allerdings benötigt Ethereum Mainnet andere Funktionen, die nur in späteren Versionen verfügbar sind. Die Client-Versionen 22.4.0 bis 22.7.0 gelten derzeit als anfällig für den Gas-Bug.
Daher müssen Besu-Client-Benutzer im Mainnet auf die gepatchte Version aktualisieren.
Auswirkung und Lösung
Danno Ferrin hat das Problem in einem Hackmd-Artikel vom 21. September ausführlich beschrieben. Ferrin’s Analyse besagt, dass
„Ein Fehler bei der Behandlung von unsignierten Daten als signierte Daten kann dazu führen, dass ein korrekt kodierter Smart Contract einen Funktionsaufruf erzeugt, der mehr Gas zurückgibt, als übergeben wurde. „
Weitere technische Informationen zu diesem Fehler finden Sie in Ferrins Beitrag. Das Wichtigste ist jedoch, dass der Fehler ohne Probleme im Ethereum Mainnet behoben wurde. Damit ein bösartiger Akteur den Fehler böswillig ausnutzen konnte, musste er auf eine bestimmte Art und Weise vorgehen:
„Um dies zu einem Chain-Halting-Bug zu machen, war ein absichtlich hergestellter Aufruf erforderlich, der einige Interaktionen mit der EIP-150 „all but one 64th“-Regel und die Reservierung eines Teils des verfügbaren Gases für den aufrufenden Vertrag beinhaltet. „
Wenn der Fehler nicht gefunden worden wäre, hätte jede Kette mit hoher Beteiligung des Besu-Clients eine „Endlosschleife“ des Smart Contracts erleben können, bei der der Vertrag „wirklich ewig ausgeführt worden wäre.“
Ferrin erklärte, dass Fuzzing es den Entwicklern ermöglichte, den Fehler ohne Probleme zu identifizieren und zu patchen. Fuzzing ist eine Methode, die von Softwareentwicklern verwendet wird, „bei der ungültige, unerwartete oder zufällige Daten als Eingaben in ein Computerprogramm eingegeben werden“.
„Die wichtigste Lehre aus diesem Exploit ist, dass der Vergleich von Trace-Daten bei einer Fuzzing-Ausführung mehr Fehler aufspürt als der einfache Vergleich der Endergebnisse. „
Der Excess-Gas-Bug wurde dank der Sorgfalt der Ethereum-Entwickler, die sich dem Schutz des Netzwerks widmen, zu einem Nicht-Ereignis. Der potenzielle Schaden, den er hätte verursachen können, zeigt jedoch die Komplexität, die hinter der problemlosen Durchführung der Zusammenführung steckt.
Der Fehler wurde in Version 22.7.1 gepatcht, indem „eine andere Konvertierungsmethode verwendet wird, die Überlaufwerte auf die maximal zu erwartenden Werte „klemmt“ und so die Probleme mit der signierten Übersetzung vermeidet.“ Ferrin kommentierte, dass Benutzer, die Nodes innerhalb des verwundbaren Bereichs betreiben, auf die neueste Version aktualisieren sollten.
