Neuer Integer-Überlauf-Bug in Solana rBPF entdeckt

Vor kurzem entdeckte unser Schwachstellenerkennungssystem ein kritisches Problem im 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 einen Integer-Überlauf-Bug handelt, der ausgenutzt werden kann, um das gesamte Solana-Netzwerk zum Absturz zu bringen. Wir haben den Bug dem Solana-Sicherheitsteam gemeldet, und das Team hat sofort Maßnahmen ergriffen, um den Bug zu bestätigen und zu beheben. Zum Zeitpunkt der Abfassung dieses Textes haben fast alle Validator-Nodes den Patch erhalten und auf die neueste Version aktualisiert, was bedeutet, dass eine öffentliche Offenlegung sicher ist.

eBPF und rBPF

Extended Berkeley Packet Filter (eBPF[1]) 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, Profiling usw. etc[2] eingesetzt. Angesichts der umfangreichen Fähigkeiten von eBPF wählte Solana es auch als Ausführungs-Engine für Smart Contracts. Um dApps auf Solana zu entwickeln, müssen Entwickler ihre Smart Contracts in Rust schreiben, die dann in eBPF-Bytecode kompiliert werden.

Um die dApps von Solana zu hosten, ist eine präzise virtuelle Maschine für eBPF erforderlich. In diesem Fall verwendet Solana rBPF, eine in Rust geschriebene virtuelle Maschine für eBPF. Ob die vorgeschlagene virtuelle Maschine (d. h. rBPF) robust, sicher und präzise ist, ist jedoch unbekannt. Sobald Sicherheitsprobleme innerhalb von rBPF auftreten, können alle rBPF enthaltenden Validatoren beeinträchtigt werden, was zu enormen Verlusten (z. B. DDoS-Angriff) für das gesamte Solana-Netzwerk führt.

Die Grundursache des Bugs

Wir haben ein Tool zur Lokalisierung von Bugs für rBPF entwickelt. Dieses Tool befindet sich noch in der aktiven Entwicklung. Während dieses Prozesses wurde ein ernstes Problem in rBPF (Version 0.2.16) identifiziert, das das gesamte Netzwerk zum Absturz bringen kann.

Genauer gesagt wird die Funktion "load" in der Datei "elf.rs" verwendet, um die ELF-Datei (den Smart Contract) zu parsen und zu verifizieren. Zuerst liest die Funktion "load" die ELF-Struktur und ruft die Funktion "relocate" auf, um den Callee-Offset einzurichten. In der Funktion "relocate" wird das Attribut "sym.st_value" jedoch direkt aus der ELF-Datei abgerufen. Wenn "st_value" groß genug ist, kann es beim Berechnen von "addr", der Summe aus "sym.st_value" und "refd_pa", zu einem Integer-Überlauf kommen.

In diesem Fall kann ein Angreifer eine bösartige ELF-Datei als Smart Contract erstellen, die den Integer-Überlauf auslösen kann. Danach würde jeder Validator die Ziel-ELF-Datei ausführen und rBPF würde mit "add with overflow" abstürzen.

In diesem Moment würde rBPF blockieren und eingehende Transaktionen würden nicht ausgeführt, was zu einem DoS-Angriff führt. Wir können beobachten, dass der Knoten aufgrund des Integer-Überlaufs beim Laden der ELF-Datei bei der "Finalisierung der Transaktion" blockiert, wie unten gezeigt.

Dieses Problem wurde in https://github.com/solana-labs/rbpf/pull/200 eingeführt, was bedeutet, dass rBPF ab Version 0.2.14 anfällig war. Wir haben das Problem identifiziert und am 6. Dezember 2021 dem Solana-Sicherheitsteam gemeldet. Solana behebt das Problem einige Stunden nach unserer Meldung durch die Verwendung des Safemath-Mechanismus. Die Korrektur befindet sich in https://github.com/solana-labs/rbpf/pull/236. Zum Zeitpunkt der Abfassung dieses Textes (30.12.2021) haben mehr als 86% der Validatoren auf die neueste Version aktualisiert.

[1] https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

[2] https://ebpf.io/