EVM-kompatible Blockchains (Ethereum Virtual Machine) sind darauf ausgelegt, mit der Smart-Contract-Funktionalität, der Programmiersprache (Solidity) und dem Tooling-Ökosystem der Ethereum-Blockchain kompatibel zu sein. Während dieses Prozesses ist die Implementierung einer EVM-konformen virtuellen Maschine einer der Schlüsselschritte. Während unserer Forschung haben wir jedoch festgestellt, dass die Aufrechterhaltung der EVM-Kompatibilität in verschiedenen Implementierungen nicht einfach ist.
Um das Problem zu lösen, hat BlockSec ein internes System entwickelt, das systematisch Fehler und Sicherheitslücken in der EVM-Implementierung aufspüren kann. Dieses System hat sich als effektiv erwiesen. Es wurden vier Fehler in Aurora Engine und vier Fehler in Moonbeam gemeldet. Alle wurden gemeldet und behoben. Beachten Sie, dass diese Testmethode auch letztes Jahr verwendet wurde, um zwei kritische Schwachstellen (CVE-2021–46102, CVE-2022–23066) in der Solana rbpf-Implementierung aufzudecken.
1. Hintergrund
Heutzutage werden viele verschiedene Blockchains mit Optimierungen für niedrige Gasgebühren, hohen Durchsatz und großartige Leistung vorgeschlagen. In diesem Fall werden neue virtuelle Maschinen oder Entwicklungssprachen vorgeschlagen, was die Hürde für die Umstellung für ursprüngliche Solidity-Entwickler erhöht. In diesem Fall werden viele EVM-kompatible Lösungen vorgeschlagen, die es Benutzern ermöglichen, ihre in Solidity entwickelten DApps auf diesen neuen Ketten bereitzustellen. Aurora und Moonbeam sind die Vertreter dieser EVM-kompatiblen Lösungen. Die Robustheit, Zuverlässigkeit und Präzision dieser EVM-Implementierungen sind jedoch unbekannt und verdienen unsere Aufmerksamkeit. Zu diesem Zweck nutzen wir die differentielle Fuzzing-Technik und prüfen, ob es Fehler in den Implementierungen gibt.
2. Differential Fuzzing
Die grundlegende Idee besteht darin, identische Eingaben an diese EVM-Implementierungen (z. B. Aurora, Moonbeam) und den State-of-the-Art-Ethereum-Client (d. h. geth) zu übergeben, um zu überprüfen, ob sie dieselbe Ausgabe haben. Speziell sammeln wir die historischen Transaktionen auf Ethereum und mutieren die Vertrags-Codes und Transaktionszustände mit verschiedenen Strategien, um Testfälle zu generieren. Unsere Ergebnisse zeigen, dass Aurora Engine und Moonbeam die Spezifikation in einigen Fällen nicht einhalten. Glücklicherweise wurden alle gemeldeten Probleme behoben, und wir werden nun die Details mitteilen.
3. Gefundene Fehler
Die meisten dieser Fehler befinden sich in den vorkompilierten Verträgen, und die Ursache und Auswirkungen sind vielfältig. Einige der Fehler können beispielsweise die Berechnung des Nonce-Werts beeinflussen, während andere die Gasberechnung beeinflussen und zu einem DoS-Angriff führen können. Alle gefundenen Fehler verstoßen gegen die vorgesehene Ausführungslogik der EVM-Spezifikation und können in bestimmten Fällen zu unerwartetem Verhalten führen. Eine detaillierte Beschreibung der gefundenen Fehler finden Sie unten.
3.1 Unzureichende Validierung
Kryptografische Logik ist komplex. In diesem Fall kann die Implementierung der entsprechenden Logik in EVM-Bytecode zu einem recht hohen Gasverbrauch führen. Stattdessen können die vorkompilierten Verträge, die in nativem Code entwickelt werden, die Leistung steigern. Wir haben jedoch mehrere Fehler in den vorkompilierten Verträgen aufgrund unzureichender Validierung gefunden.
Aurora Engine: ecPairing
Dieser Fehler wurde im vorkompilierten Vertrag ecPairing gefunden.
Die Eingabe von ecPairing besteht aus mehreren Punkten auf zwei elliptischen Kurven. Gemäß der Spezifikation liegt der Punkt (0, 0) auf beiden Kurven und sollte eine gültige Eingabe sein:
Aurora Engine (Version 2.7.0) wird jedoch zurückgesetzt, wenn der Punkt (0,0) in der Eingabe enthalten ist:
Der zugehörige PR ist hier.
Moonbeam: ecMul
Dieser Fehler liegt im vorkompilierten Vertrag ecMul. Anders als bei Aurora Engine setzt Moonbeam die Transaktion zurück, wenn die Eingabe gültig ist. Gemäß der Spezifikation sollte der vorkompilierte Vertrag ecMul die Eingabe mit Nullen auffüllen, wenn die Länge der Eingabe kleiner als 64 ist. Moonbeam setzt jedoch zurück, anstatt die Auffüllung durchzuführen.
Wir haben auch festgestellt, dass die vorkompilierten Verträge ecAdd und modexp das gleiche Problem aufweisen.
Der zugehörige PR ist hier.
Moonbeam: ecRecover
Dieser Fehler liegt im vorkompilierten Vertrag ecRecover, der zur Wiederherstellung der Ethereum-Adresse verwendet wird.
Gemäß der Spezifikation stellt input[32..63] v einen U256-Identifikator dar und sollte entweder 27 oder 28 sein, andernfalls sollte ecRecover nichts zurückgeben (aber die gesamte Transaktion sollte nicht zurückgesetzt werden).
Moonbeam macht hier jedoch zwei Fehler:
- Es wird nur
input[63]geprüft, anstattinput[32..63]in einen U256-Typ umzuwandeln und dann den Wert zu prüfen. - Die Eingabe wird als gültig betrachtet, wenn der Identifikator 0 oder 1 ist (er sollte nur 27 oder 28 sein).
Der zugehörige PR ist hier.
Moonbeam: ecPairing
Dieser Fehler liegt im vorkompilierten Vertrag ecPairing. Moonbeam setzt die Transaktion nicht zurück, wenn die Eingabe ungültig ist. Gemäß der Spezifikation sollte die Eingabe des vorkompilierten Vertrags ecPairing ein Vielfaches von 192 sein. Andernfalls sollte die Transaktion zurückgesetzt werden.
Moonbeam setzt die Transaktion jedoch nicht zurück, wenn die oben genannten Anforderungen nicht erfüllt sind.
Der zugehörige PR ist hier.
3.2 Falsche Gasberechnung
Jeder vorkompilierte Vertrag hat einen Algorithmus zur Ermittlung des Gasverbrauchs. Eine falsche Gasberechnung kann zu einem DoS-Angriff führen.
Wir haben jedoch zwei Fehler sowohl in Aurora Engine als auch in Moonbeam gefunden, bei denen die Gasberechnung falsch ist.
Aurora Engine: modexp
Der Fehler liegt im vorkompilierten Vertrag modexp. Der Algorithmus zur Berechnung des Gasverbrauchs ist in EIP-2565 definiert. Der Gasverbrauch hängt von der Anzahl der Iterationen ab.
Der Algorithmus zur Berechnung der Iterationsanzahl lautet wie folgt:
def calculate_iteration_count(exponent_length, exponent):
iteration_count = 0
if exponent_length <= 32 and exponent == 0: iteration_count = 0
elif exponent_length <= 32: iteration_count = exponent.bit_length() - 1
elif exponent_length > 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
return max(iteration_count, 1)
Gemäß dem obigen Algorithmus beträgt die Iterationsanzahl mindestens eins. Aurora Engine gibt jedoch die iteration_count direkt zurück, anstatt max(iteration_count, 1). In diesem Fall kann der zurückgegebene Wert (d. h. iteration_count) 0 sein, was bedeutet, dass Aurora in bestimmten Fällen eine wesentlich geringere Gasgebühr als erwartet berechnet.
Der zugehörige Issue-Link ist hier.
Moonbeam: modexp
Der Fehler liegt auch in der Funktion calculate_iteration_count des vorkompilierten Vertrags modexp. Er wurde jedoch in Moonbeam gefunden.
Wenn die exponent_length größer als 32 ist, wird die iteration_count mit dem folgenden Algorithmus berechnet:
(8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
Beachten Sie, dass hier exponent & (2**256 - 1) verwendet wird, was die niedrigsten 32 Bytes von exponent nimmt, und die Implementierung von Moonbeam folgt diesem Algorithmus.
Gemäß der Spezifikation sollte die Gasberechnungsformel jedoch die höchsten 32 Bytes von exponent verwenden:
Der zugehörige PR ist hier.
3.3 Nonce-Inkrementierungsfehler
Die Nonce eines externen Kontos (EOA) gibt die Anzahl der erfolgreichen Transaktionen an, die von dieser Adresse signiert wurden. Wir haben jedoch festgestellt, dass die Nonce durch das Senden ungültiger Transaktionen auf Aurora Engine erhöht werden kann.
Gemäß EIP-1559 sollte die EVM vor der Ausführung einer Transaktion sicherstellen, dass der Unterzeichner über ausreichend Guthaben verfügt, um den übertragenen nativen Token (z. B. ETH) und das erforderliche Gas abzudecken. Andernfalls sollte die Transaktion verworfen und die Nonce des Unterzeichners nicht erhöht werden.
Obwohl Aurora Engine die Transaktion in dieser Situation verwirft, erhöht es dennoch die Nonce des Unterzeichners.
Der zugehörige PR ist hier.
3.4 Falsche Opcode-Implementierung
Bei diesem Fehler geht es um die Implementierung eines bestimmten Opcodes (d. h. PUSH). Wenn die Bytes nach dem PUSH-Opcode unvollständig sind, sollten sie rechtsbündig ausgerichtet werden. Zum Beispiel kann der Bytecode 0x64ffff wie folgt dekodiert werden:
PUSH5 0xffff
Da der Operand rechtsbündig ausgerichtet sein sollte, sollte der Wert 0xffff000000 auf den Stack gepusht werden. Die EVM-Implementierungen in Aurora Engine und Moonbeam pushen stattdessen 0xffff, was falsch ist.
Der zugehörige PR ist hier.
4. Unser Service
Bei BlockSec verstehen wir die Bedeutung der Aufrechterhaltung der EVM-Kompatibilität und -Sicherheit über verschiedene Blockchain-Implementierungen hinweg. Deshalb haben wir einen systematischen Ansatz zur Fehlererkennung entwickelt, der Schwachstellen in EVM-Implementierungen mit Leichtigkeit aufspüren kann.
Unser internes System hat sich bei der Aufdeckung von Fehlern und Sicherheitslücken in EVM-Implementierungen als äußerst effektiv erwiesen. Es hat erfolgreich vier Fehler in Aurora Engine und vier Fehler in Moonbeam gemeldet und behoben. Darüber hinaus wurde unsere Testmethodik letztes Jahr zur Aufdeckung zweier kritischer Schwachstellen (CVE-2021–46102, CVE-2022–23066) in der Solana rbpf-Implementierung verwendet, was die Wirksamkeit unseres Ansatzes unterstreicht.
Durch die Implementierung unseres systematischen Ansatzes zur Fehlererkennung können unsere Kunden sicher sein, dass ihre EVM-Implementierungen sicher und zuverlässig sind. Wir engagieren uns für die Bereitstellung erstklassiger Lösungen für EVM-Kompatibilität und -Sicherheit, um unseren Kunden zu helfen, Vertrauen bei ihren Benutzern und Stakeholdern aufzubauen.
Über BlockSec
Das BlockSec-Team konzentriert sich auf die Sicherheit des Blockchain-Ökosystems und arbeitet mit führenden DeFi-Projekten zusammen, um deren Produkte zu sichern. Das Team wurde von erstklassigen Sicherheitsexperten und erfahrenen Experten aus Wissenschaft und Industrie gegründet. Sie haben mehrere Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe von DeFi-Anwendungen gemeldet und detaillierte Analyseberichte zu sicherheitsrelevanten Vorfällen mit hoher Auswirkung veröffentlicht.
