Warum nicht die Richtlinie „externe Aufrufe zuletzt“ syntaktisch (oder im Compiler) erzwingen, um wiedereintrittsfähige Angriffe zu verhindern?

Aus den Dokumenten :

Schreiben Sie Ihre Funktionen so, dass beispielsweise Aufrufe externer Funktionen nach Änderungen an Zustandsvariablen in Ihrem Vertrag erfolgen, damit Ihr Vertrag nicht anfällig für einen Reentrancy-Exploit ist.

Ich habe mich gefragt, ob es möglich (und praktikabel) ist, diese Regel syntaktisch oder als Überprüfung im Compiler durchzusetzen, um diese Klasse von Angriffen zu verhindern.

Wenn es nicht möglich ist, warum? Gibt es eine Notwendigkeit, externe Anrufe irgendwo in der Mitte von Funktionen zuzulassen?


Ich bin auf EIP 214 gestoßen, in dem es heißt:

Dieser Vorschlag fügt einen neuen Opcode hinzu, der verwendet werden kann, um einen anderen Vertrag (oder sich selbst) aufzurufen, während während des Aufrufs jegliche Änderungen des Zustands (und seiner Unteraufrufe, falls vorhanden) nicht zugelassen werden.

Es hört sich so an, als würde es das Problem ansprechen, aber vom anderen Ende. Meine Frage konzentriert sich auf das Erzwingen von nicht statischen Aufrufen, die innerhalb von Funktionen immer als letztes platziert werden.

Antworten (1)

Diese Regel ist tatsächlich relativ einfach zu formalisieren. Statische Analysetools wie Securify identifizieren diese Schwachstelle (siehe ihr vorinstalliertes Beispiel).

Gibt es Pläne, diese Prüfungen in den Compiler aufzunehmen?
@scriptin nicht, dass ich wüsste ... Eine zukünftige vollwertige Ethereum-IDE wird vor der Kompilierung einen statischen Analysator ausführen und Dinge wie Warnungen anzeigen, das erwarte ich.