Wie ein kritischer Fehler im Solana-Netzwerk erkannt und rechtzeitig behoben wurde

Im April entdeckte unser System zur Erkennung von Schwachstellen ein Problem in der rBPF von Solana (d. h. der virtuellen Maschine, auf der alle Solana dApps laufen: https://github.com/solana-labs/rbpf). Nach sorgfältiger Untersuchung stellten wir fest, dass es sich um eine Sicherheitslücke handelt, die zu einem falschen Ausführungspfad eines Vertrags führen kann. Wir haben den Fehler dem Solana-Sicherheitsteam gemeldet, und das Team hat die Schwachstelle sofort bestätigt und behoben. Außerdem hat uns das Team einen Betrag im Wert von 800.000 US-Dollar in SoL-Token gewährt.

Die Schwachstelle besteht in neueren Versionen von rBPF (0.2.26 bis 0.2.27). Als wir das Problem meldeten, waren die auf dem Mainnet verwendeten Validatoren noch nicht auf die betroffenen Versionen aktualisiert worden. Unser System erkannte das Problem, bevor die betroffene Version zusammengeführt wurde, wodurch die Validatoren des Mainnets immun gegen diese Schwachstelle waren.

Im Folgenden erläutern wir die Details dieser Schwachstelle.

1. eBPF und rBPF

eBPF (Extended Berkeley Packet Filter) wurde ursprünglich zur Paketfilterung im Kernel entwickelt. Aufgrund der Sicherheit, Effizienz und Skalierbarkeit von eBPF wird es heute in verschiedenen Bereichen wie Netzwerken, Tracing und Profiling eingesetzt. Angesichts der reichen Fähigkeiten von eBPF nutzt Solana es als Ausführungs-Engine für Smart Contracts. Um dApps auf Solana zu entwickeln, schreiben Entwickler ihre Smart Contracts in Rust und kompilieren den Vertrag in eBPF-Bytecode.

Solana verwendet rBPF, eine in Rust geschriebene virtuelle Maschine, um den kompilierten BPF-Bytecode auszuführen. Es ist jedoch unklar, ob die vorgeschlagene virtuelle Maschine (d. h. rBPF) robust, sicher und präzise ist. Wenn Sicherheitsprobleme innerhalb von rBPF bestehen, können alle rBPF enthaltenden Validatoren betroffen sein, was zu enormen Verlusten (z. B. Verlust von Geldern) für das gesamte Solana-Netzwerk führen kann.

2. Grundursache

Wir haben ein Werkzeug entwickelt, das Implementierungsfehler von rBPF automatisch lokalisieren und den Code von rBPF periodisch scannen kann. Bei einem Scanprozess wurde ein ernstes Problem in rBPF (Version 0.2.26) identifiziert, das zu einem falschen Ausführungspfad eines Vertrags führen kann.

Insbesondere wird die sdiv-Anweisung als vorzeichenbehaftete Divisionsanweisung verwendet, die als standardmäßig aktivierte Funktion in rbpf 0.2.26 eingeführt wurde. sdiv unterstützt die Division für Operanden sowohl in 32-Bit (sdiv32) als auch in 64-Bit (sdiv64). Für die sdiv32-Anweisung wird das Berechnungsergebnis im bpf-Register gespeichert, das ein 64-Bit-Register ist. Wenn jedoch die Anweisungen nach der sdiv32-Anweisung das Berechnungsergebnis als 64-Bit lesen, kann das Ergebnis abweichen. Dies liegt daran, dass rBPF das Berechnungsergebnis von sdiv32 während der JIT-Kompilierung nicht auf den korrekten Wert in 64-Bit erweitert.

Als Beispiel: Wenn eine positive Zahl (d. h. 12) durch eine negative Zahl (d. h. -4) mit sdiv32 geteilt wird, sollte das korrekte Ergebnis sowohl in 32-Bit als auch in 64-Bit -3 sein. Der folgende Code ist ein Beispiel.

Nachdem wir ihn im JIT- und im Interpretierten Modus ausgeführt und verfolgt haben, konnten wir die Unterschiede zwischen ihnen beobachten:

2.1 Interpretierten Modus

0 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    29: lddw r5, 0x10000000c
 1 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 000000010000000C, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    31: sdiv32 r5, -4
 2 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, FFFFFFFFFFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    32: jslt r5, 0, lbb_7
 3 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, FFFFFFFFFFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    36: exit

2.2 JIT Modus

0 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    29: lddw r5, 0x10000000c
 1 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 000000010000000C, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    31: sdiv32 r5, -4
 2 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    32: jslt r5, 0, lbb_7
 3 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    33: lddw r0, 0x1
 4 [0000000000000001, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    35: exit

Im Interpretierten Modus wird das Register r5 auf 0xFFFFFFFFFFFFFFFD (-3 sowohl im 32-Bit- als auch im 64-Bit-Modus) gesetzt, während im JIT-Modus r5 auf 0x00000000FFFFFFFD gesetzt wird. In diesem Fall wird r5 für die jslt-Anweisung, die einen 64-Bit-Wert erhält, als positive Zahl (d. h. 0x00000000FFFFFFFD) erkannt. Danach wird der Ausführungspfad völlig falsch sein.

3. Auswirkungen

Diese falsche Implementierung kann zu einem fehlerhaften Ausführungspfad eines Vertrags führen und schwerwiegende Probleme verursachen.

Wenn beispielsweise eine wesentliche Operation in einem Smart Contract vom Ergebnis der sdiv32-Anweisung abhängt, kann dies zu falschen Ausführungsergebnissen führen und von Angreifern missbraucht werden.

Dieses Problem wurde in https://github.com/solana-labs/rbpf/pull/283 eingeführt, was bedeutet, dass rBPF ab Version 0.2.26 anfällig ist. Wir haben das Problem identifiziert und dem Solana-Sicherheitsteam am 28. April 2022 gemeldet. Das Team reagierte schnell auf unseren Bericht und behob das Problem innerhalb weniger Stunden, indem es die Vorzeichenerweiterung für die sdiv32-Anweisung hinzufügte. Die Korrektur ist in https://github.com/solana-labs/rbpf/pull/310 enthalten. Aufgrund der rechtzeitigen Erkennung und Meldung durch unser Team waren die Validatoren des Mainnets von dieser Schwachstelle nicht betroffen.

Dieses Problem wird als Protokoll-Liveness-Bug klassifiziert, was zu einer von Solana gewährten Bug-Bounty von 800.000 US-Dollar führte.

Zeitplan

• 28.04.2022: Wir haben das Problem dem Solana-Sicherheitsteam gemeldet
• 29.04.2022: Die Schwachstelle wurde behoben
• 09.05.2022: CVE-2022-23066 wurde zugewiesen
• 01.06.2022: Die Bug-Bounty wurde gewährt

Ü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 wird von erstklassigen Sicherheitsexperten und erfahrenen Experten aus Wissenschaft und Wirtschaft gegründet. Sie haben mehrere Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet und detaillierte Analysen hochwirksamer Sicherheitsvorfälle veröffentlicht.

Twitter: [BlockSecTeam]

Medium: https://blocksecteam.medium.com

Website: https://www.blocksec.com