9 der Top 10 TVL-Ketten unterstützen EVM-Smart-Verträge.
Originaltitel: „How to uate Forked EVMs for Security Risks“
Beiträge: Ethan Pociask, Eric Meng, Nadir Akhtar, Gabriela Melendez Quan, Tom Ryan
Compiler: Katie Koo
Um die Sicherheits- und Verwahrungszusicherungen für Kunden zu stärken, die ERC-20 und andere auf Smart Contracts basierende Vermögenswerte handeln, untersuchte das Coinbase Blockchain Security-Team die programmatische Schicht, die das Verhalten dieser Vermögenswerte definiert: die Ethereum Virtual Machine (EVM). Bei der Bewertung von Projekten, die die EVM ihres eigenen Netzwerks ändern, überprüft das Blockchain-Sicherheitsteam von Coinbase wichtige EVM-Änderungen, um festzustellen, ob die geänderte EVM die gleichen Sicherheits- und Verwahrungsgarantien wie die ursprüngliche EVM-Implementierung bieten kann.
Fork-EVM-Status
Seit Mai 2023 hat die Ethereum Virtual Machine (EVM) den Titel „Big Brother“ der beliebtesten Plattform zur Ausführung intelligenter Verträge gewonnen. Laut DefiLlama unterstützen 9 der Top-10-Ketten von Total Value Locked (TVL) EVM-Smart-Verträge. Daher ist ein tiefes Verständnis des EVM von entscheidender Bedeutung für die Unterstützung intelligenter Verträge im gesamten Blockchain-Ökosystem.
EVM ist eine virtuelle Maschine zur dezentralen Ausführung von Smart Contracts im Ethereum-Netzwerk. Viele EVM-kompatible Blockchains nutzen Standardimplementierungen beliebter Ethereum-Implementierungsclients in verschiedenen Sprachen wie go-ethereum (Golang) und besu (Java) direkt in ihrer Protokollsoftware.
Allerdings ist das Forken und Modifizieren der EVM im Blockchain-Ökosystem tatsächlich weit verbreitet, selbst innerhalb wichtiger Protokolle. Beispielsweise verwendet der Optimism Bedrock Stack, der die Base-L2-Blockchain von Coinbase „antreibt“, einen Fork des Go-Ethereum-Ausführungsclients namens op-geth, der das gleiche EVM wie der beliebte Ethereum-Ausführungsclient ausführt. kompatibel. Dies bedeutet jedoch nicht, dass sich die EVM auf Ethereum genau so verhält wie die EVM auf Optimism: Die Op-Geth-EVM verhält sich in einigen Fällen etwas anders (d. h. die SCHWIERIGKEIT bei der Rückgabe zufälliger Werte wird vom Sequenzer bestimmt).
Auch wenn das beängstigend klingt, ist es im Allgemeinen für die EVM-Einführung von Vorteil. Während die Standard-EVM-Implementierung stark für das Basisprotokoll von Ethereum optimiert ist, erweitern gespaltene EVMs sie häufig für neue eigene Protokolle. Infolgedessen können Verträge auf einigen EVM-kompatiblen Ketten anders ausgeführt werden als auf Ethereum, und die Sicherheitsannahmen für das Verhalten intelligenter EVM-Verträge können auch zwischen verschiedenen Protokollen stark variieren.
Forken Sie das EVM-Sicherheitsframework
Zu diesem Zweck hat Coinbase ein Web3-Sicherheitsframework zur Bewertung der Sicherheitsauswirkungen einiger gespaltener EVM-Implementierungen entwickelt. Wir nennen es das geforkte EVM-Framework von Coinbase, das im Folgenden ausführlich erläutert wird.
Mit diesem gespaltenen EVM-Sicherheitsframework ist Coinbase in der Lage, effektiv:
- Das Verständnis der Ungültigkeit der Sicherheitsannahmen unseres Ethereum-Token-Frameworks ermöglicht es uns, neue EVM-kompatible Blockchains sicher zu ermöglichen, ERC-20/ERC-721-Tokens auf unseren dezentralen Börsen zu unterstützen;
- Bereitstellung einer Analyse der Smart-Contract-Schwachstellensituation der gespaltenen EVM für Smart-Contract-Prüfer, insbesondere kleiner Unterschiede im Netzwerk;
- Gewährleisten Sie die sichere Nutzung und Ausführung von EVM-Smart-Verträgen auf der Base-L2-Blockchain von Coinbase.
Sicherheitsstandard für EVM-kompatible Blockchains
Um zu verstehen, welche Sicherheitsrisiken in der virtuellen Maschine von Ethereum bestehen, müssen wir zunächst wissen, welche Garantien uns die Standard-EVM-Implementierung bietet. Wir definieren die Standard-EVM als die EVM, die von Ethereum-Validator-Ausführungsclients konsequent verwendet wird, wie in der Ethereum-Implementierungsspezifikation beschrieben. Der mit Abstand am häufigsten verwendete Client ist Go Ethereum (dh Geth).
Wir fassen die Sicherheit in zwei Sicherheitskriterien zusammen, die die Mindestanforderungen für jede geforkte EVM-Implementierung darstellen, um für Coinbase-Unterstützung in Frage zu kommen.
Wie prüfen wir die Sicherheitsrisiken einer EVM-Implementierung?
Unser gespaltenes EVM-Framework konzentriert sich auf die folgenden Prüfanforderungen bei der Bewertung der Einhaltung allgemeiner Sicherheitskriterien (d. h. Vertragsunveränderlichkeit und eine sichere Ausführungsumgebung). Es ist zu beachten, dass die folgenden Risikokomponenten nicht den gesamten Umfang des Fork-EVM-Audits abdecken.
Eine Änderung der Definition und Kodierung von EVM-Opcodes kann zu erheblichen Unterschieden bei der Vertragsausführung führen. Angenommen, eine gegabelte EVM-Implementierung (EVM’) ändert den arithmetischen ADD-Opcode, um die Logik (x1 + x2) zum Subtrahieren zweier Werte (x1 – x2) zu definieren.
Infolgedessen ist die abweichende EVM ungleich und in der Ausführung mit der Standard-EVM nicht kompatibel. Die Folgen der Änderung von Opcodes können vorteilhaftes Verhalten sein, wie z. B. die Verhinderung eines Ganzzahlüberlaufs und -unterlaufs in arithmetischen Opcodes, oder gefährlicheres Verhalten, wie z. B. Selbstzerstörungsverhalten, das zu einer unbegrenzten Prägung lokaler Assets führt.
EVM verwendet vorkompilierte Verträge, um komplexe Funktionen (z. B. Verschlüsselungsfunktionen) zu definieren, und verwendet dabei eine bequemere und leistungsfähigere Sprache wie Golang, anstatt den weniger zugänglichen EVM-Bytecode zu verwenden.
Im Wesentlichen handelt es sich dabei um programmierte Funktionen, auf die über vorgegebene Kettenadressen zugegriffen wird, die in der Knotensoftware dargestellt werden. Im Ethereum Yellow Paper sind 9 Precompiler definiert (Stand Mai 2023), und alle Änderungen an diesen 9 Precompilern oder die Einführung neuer Precompiler müssen geprüft werden.
Nehmen wir ein weiteres konkretes Beispiel – die Sicherheitslücke in der BNB Smart Chain. Die BNB Smart Chain verwendet eine abweichende Implementierung von Go-Ethereum, um Knoten zu betreiben. Zu diesem Zweck werden zwei neue vorkompilierte Verträge (tmHeaderValidate, iavlMerkleProofValidate) eingeführt, um Software von Drittanbietern (z. B. Cosmos SDK) zur Durchführung einer leichten Client-Blockvalidierung und Merkle-Proof-Validierung zu nutzen. Das Problem besteht darin, dass die Cosmos SDK-Software einen Implementierungsfehler in der IAWL-Baumdarstellung aufweist, der es kryptografisch ungültigen Beweisen ermöglicht, die Überprüfung zu bestehen. Mit anderen Worten: Jeder kann Geld aus dem Nichts generieren. Angreifer konnten diesen Implementierungsfehler im Precompiler iavlMerkleProofValidate ausnutzen, um Hunderte Millionen Dollar von der Binance-Cross-Chain-Brücke abzuschöpfen.
Dieses Exploit-Beispiel soll die Notwendigkeit von Precompiler-Sicherheit und die potenziellen Risiken der Einführung neuer vorkompilierter Verträge für abweichende EVM-Implementierungen verdeutlichen.
Zu den potenziell fatalen Risiken der Einführung zusätzlicher Precompiler gehören:
- Ermöglichen Sie einer Partei, den Status eines bereitgestellten Vertrags einseitig zu ändern.
- Dazu gehören alle Speicheränderungen (Einfügungen, Aktualisierungen, Löschungen);
- Verwendung nicht vertrauenswürdiger, ungeprüfter oder ungeprüfter Abhängigkeiten Dritter;
- Bietet Zugriff auf den Wert innerhalb des unbestimmten Knotens.
Obwohl der Compiler und die EVM als völlig separate Einheiten behandelt werden, ist es erwähnenswert, dass der Solidity-Compiler strenge Annahmen über das Verhalten der ersten drei vorkompilierten Verträge (ecrecover, sha256 und &ripemd) trifft, die über die Schlüsselwortfunktion der Muttersprache von Solidity übergeben werden Darstellung in der Sprache. Hinter den Kulissen verarbeitet der Solidity-Compiler diese Schlüsselwörter tatsächlich in Bytecode, der statische Aufrufe zwischen Verträgen ausführt. Das folgende Diagramm veranschaulicht diese Art der Kommunikation zwischen Verträgen weiter.
Zu den Sicherheitsrisiken, die durch die Änderung des Standard-Precompilers entstehen, gehören:
- Ermöglichen Sie zentralisierten Gegenparteien, den Status eines bereitgestellten Vertrags einseitig zu ändern.
- Dazu gehören alle Speicheränderungen (Einfügungen, Aktualisierungen, Löschungen);
- Die Annahme der Vorkompilierungsposition des Solidity-Compilers ist inkonsistent;
- Bietet Zugriff auf Werte innerhalb unbestimmter Knoten;
- Verwendung nicht vertrauenswürdiger, nicht überprüfter oder ungeprüfter Abhängigkeiten von Drittanbietern.
Zu den Hauptrisiken, die durch die Änderung grundlegender Komponenten des EVM entstehen, gehören:
- schränkt den Interpreterstapel nicht auf eine unendliche Größe ein;
- Eine Größenänderung oder Änderung des Speichermodells kann zu einer nicht deterministischen Ausführung führen.
- Zugriffskontrolle umgehen, sodass jede Gegenpartei einseitig auf alle Kettenzustände zugreifen kann;
- Verwendung nicht vertrauenswürdiger, nicht überprüfter oder ungeprüfter Abhängigkeiten von Drittanbietern.
Warum sollten wir auf die EVM-Sicherheit achten?
Unser Ziel ist es, ein offenes Finanzsystem auf Basis der Blockchain-Technologie aufzubauen. Zu diesem Zweck fördern wir die Entwicklung verschiedener EVM-Implementierungen. Damit eine EVM-kompatible Blockchain jedoch vollständig von Coinbase unterstützt wird, muss sie die grundlegenden Anforderungen einer Standard-EVM-Implementierung erfüllen. Ziel dieses Dokuments ist es, das Bewusstsein für die mit einer Abweichung von der EVM verbundenen Risiken zu schärfen und Vermögensemittenten zu ermutigen, der Entwicklung sicherer Komponenten bei einer Abweichung von der EVM Vorrang einzuräumen, wodurch das Sicherheitsbewusstsein im gesamten Web3-Ökosystem erhöht wird.
