Sicherheitslücken in Etherium Smart-Verträgen. Codebeispiele

Mit diesem Beitrag beginne ich eine Reihe von Artikeln zur Sicherheit von Ethereum-Smart-Verträgen. Ich denke, dieses Thema ist sehr relevant, da die Anzahl der Entwickler wie eine Lawine wächst und es niemanden gibt, der vor dem "Rechen" gerettet werden kann. Tschüss - Übersetzungen ...

1. Scannen von Live Ethereum-Verträgen auf nicht aktivierte Sendefehler

Original - Scannen von Live Ethereum-Verträgen für "Unchecked-Send ..."

Autoren: Zikai Alex Wen und Andrew Miller

Die intelligente Vertragsprogrammierung von Ethereum ist bekanntermaßen fehleranfällig [1] . Vor kurzem haben wir das mehrere gesehen
High-End-Smart-Verträge wie King of the Ether und The DAO-1.0 enthielten Schwachstellen, die durch Programmierfehler verursacht wurden.

Seit März 2015 werden intelligente Vertragsprogrammierer vor spezifischen Programmiergefahren gewarnt, die auftreten können, wenn Verträge Nachrichten aneinander senden [6] .

In mehreren Programmierhandbüchern wird empfohlen, häufige Fehler zu vermeiden (in White Papers Ethereum [3] und in einem unabhängigen Handbuch von UMD [2] ). Obwohl diese Gefahren verständlich genug sind, um sie zu vermeiden, sind die Folgen eines solchen Fehlers schrecklich: Geld kann blockiert, verloren oder gestohlen werden.

Wie häufig treten Fehler aufgrund dieser Gefahren auf? Gibt es verletzlichere, aber lebende Ethereum-Blockchain-Verträge? In diesem Artikel beantworten wir diese Frage, indem wir Verträge in der Live-Blockchain von Ethereum mit dem von uns entwickelten neuen Analysetool analysieren.

Was ist der nicht aktivierte Sendefehler?

Um einen Sendezeitvertrag an eine andere Adresse zu senden, verwenden Sie am einfachsten das Schlüsselwort send . Dies fungiert als für jedes Objekt definierte Methode. Das folgende Codefragment befindet sich beispielsweise in einem intelligenten Vertrag, der ein Brettspiel implementiert.

/*** Listing 1 ***/ if (gameHasEnded && !( prizePaidOut ) ) { winner.send(1000); //    prizePaidOut = True; } 

Das Problem hierbei ist, dass die Sendemethode möglicherweise fehlschlägt. Wenn es nicht funktioniert, erhält der Gewinner das Geld nicht, die Variable pricePaidOut wird jedoch auf True gesetzt.

Es gibt zwei verschiedene Fälle, in denen die Funktion won.send () möglicherweise fehlschlägt. Wir werden den Unterschied zwischen ihnen später analysieren. Der erste Fall ist, dass die Gewinneradresse ein Vertrag ist (kein Benutzerkonto) und der Code für diesen Vertrag eine Ausnahme auslöst (z. B. wenn zu viel „Gas“ verwendet wird). Wenn ja, dann ist es in diesem Fall vielleicht ein "Fehler des Gewinners". Der zweite Fall ist weniger offensichtlich. Die virtuelle Ethereum-Maschine verfügt über eine begrenzte Ressource namens " Callstack " (Call-Stack-Tiefe). Diese Ressource kann von einem anderen Vertragscode verwendet werden, der zuvor in einer Transaktion ausgeführt wurde. Wenn der Callstack zum Zeitpunkt der Ausführung des Sendebefehls bereits aufgebraucht war, schlägt der Befehl fehl, unabhängig davon, wie der Gewinner ermittelt wird. Der Preis des Gewinners wird unverschuldet vernichtet!

Wie kann dieser Fehler vermieden werden?

Die Ethereum-Dokumentation enthält eine kurze Warnung zu dieser potenziellen Gefahr [3] : "Bei Verwendung von send besteht eine gewisse Gefahr - die Übertragung schlägt fehl, wenn die Tiefe des Aufrufstapels 1024 beträgt (dies kann immer vom Anrufer verursacht werden), und schlägt auch fehl, wenn der Empfänger "Gas" endet. Um eine sichere Übertragung zu gewährleisten, überprüfen Sie daher immer den Rückgabewert von " Senden" oder besser: Verwenden Sie eine Vorlage, in der der Empfänger Geld abhebt. "

Zwei Sätze. Der erste besteht darin, den Rückgabewert von send zu überprüfen, um festzustellen , ob er erfolgreich abgeschlossen wurde. Wenn dies nicht der Fall ist, lösen Sie eine Ausnahme aus, um den Status zurückzusetzen.

  /*** Listing 2 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000)) prizePaidOut = True; else throw; } 

Dies ist eine angemessene Lösung für das aktuelle Beispiel, aber nicht immer die richtige Entscheidung. Angenommen, wir ändern unser Beispiel so, dass der Gewinner und der Verlierer nach dem Spiel ihr Vermögen zurückdrehen. Eine offensichtliche Anwendung einer „formalen“ Lösung wäre die folgende:

 /*** Listing 3 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000) && loser.send(10)) prizePaidOut = True; else throw; } 

Dies ist jedoch ein Fehler, da dadurch eine zusätzliche Sicherheitsanfälligkeit entsteht. Während dieser Code den Gewinner vor einem Callstack- Angriff schützt, macht er Gewinner und Verlierer auch für einander anfällig. In diesem Fall möchten wir einen Callstack- Angriff verhindern, aber die Ausführung fortsetzen, wenn der Sendebefehl aus irgendeinem Grund fehlschlägt.

Daher ist es selbst die beste bewährte Methode (empfohlen in unserem Ethereum and Serpent Programmer's Guide, obwohl dies auch für Solidity gilt), nach einer Callstack- Ressource zu suchen . Wir können ein Makro callStackIsEmpty () definieren , das genau dann einen Fehler zurückgibt, wenn callstack leer ist.

 /*** Listing 4 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (callStackIsEmpty()) throw; winner.send(1000) loser.send(10) prizePaidOut = True; } 

Noch besser ist, dass die Empfehlung aus der Ethereum-Dokumentation - „Verwenden Sie eine Vorlage, in der der Empfänger das Geld nimmt“ - etwas kryptisch ist, aber eine Erklärung enthält. Der Vorschlag besteht darin, Ihren Code so zu reorganisieren, dass die Auswirkung des Sendefehlers isoliert ist und jeweils nur einen Empfänger betrifft. Das Folgende ist ein Beispiel für diesen Ansatz. Dieser Tipp ist jedoch auch ein Anti-Muster. Er übernimmt die Verantwortung für die Überprüfung des Callstacks gegenüber den Empfängern selbst, wodurch es möglich wird, in dieselbe Falle zu tappen.

 /*** Listing 5 ***/ if (gameHasEnded && !( prizePaidOut ) ) { accounts[winner] += 1000 accounts[loser] += 10 prizePaidOut = True; } ... function withdraw(amount) { if (accounts[msg.sender] >= amount) { msg.sender.send(amount); accounts[msg.sender] -= amount; } } 

Viele hochentwickelte intelligente Verträge sind anfällig. Die Lotterie "König der Luft des Throns" ist der bekannteste Fall dieses Fehlers [4] . Dieser Fehler wurde erst bemerkt, als die Menge von 200 Ethern (im Wert von mehr als 2000 US-Dollar zum heutigen Preis) nicht den legitimen Gewinner der Lotterie erhalten konnte. Der entsprechende Code in King of the Ether ähnelt dem Code in Listing 2. Glücklicherweise konnte der Vertragsentwickler in diesem Fall die nicht verwandte Funktion im Vertrag als „manuelle Überschreibung“ verwenden, um die festgefahrenen Gelder freizugeben. Ein weniger gewissenhafter Administrator könnte dieselbe Funktion verwenden, um die Sendung zu stehlen!

Fortsetzung des Scannens von Live Ethereum-Verträgen auf nicht aktivierte Sendefehler. Teil 2