Kürzlich hat unser System zur Erkennung von Schwachstellen ein kritisches Problem im rBPF von Solana (d.h. der virtuellen Maschine, auf der alle Solana-dApps laufen: https://github.com/solana-labs/rbpf) entdeckt. Nach sorgfältiger Untersuchung stellten wir fest, dass es sich um einen Integer-Overflow-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 Erstellung dieses Berichts haben fast alle Validator-Knoten den Patch erhalten und sind auf die neueste Version aktualisiert worden, was bedeutet, dass eine öffentliche Offenlegung nun 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 reichhaltigen Fähigkeiten von eBPF hat Solana es auch als Ausführungs-Engine für Smart Contracts gewählt. 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) jedoch robust, sicher und präzise ist, ist unbekannt. Sobald Sicherheitsprobleme innerhalb von rBPF bestehen, können alle rBPF enthaltenden Validatoren beeinflusst werden, was zu enormen Verlusten (z. B. DDoS-Angriffe) 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 schwerwiegendes Problem in rBPF (Version 0.2.16) identifiziert, das das gesamte Netzwerk lahmlegen 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 ein Integer-Overflow beim Berechnen von "addr", der Summe aus "sym.st_value" und "refd_pa", ausgelöst werden.
In diesem Fall kann ein Angreifer eine bösartige ELF-Datei als Smart Contract erstellen, die den Integer-Overflow auslöst. Danach würde jeder Validator die Ziel-ELF-Datei ausführen und rBPF würde mit „add with overflow“ abstürzen.
In diesem Moment gerät rBPF ins Stocken und eingehende Transaktionen werden nicht ausgeführt, was zu einem DoS-Angriff führt. Wir können beobachten, dass der Knoten aufgrund des Integer-Overflows beim Laden der ELF-Datei bei „Finalizing transaction“ hängt, wie im Folgenden gezeigt.
Dieser Fehler wurde in https://github.com/solana-labs/rbpf/pull/200 eingeführt, was bedeutet, dass rBPF ab Version 0.2.14 anfällig ist. Wir haben das Problem identifiziert und am 6. Dezember 2021 dem Solana-Sicherheitsteam gemeldet. Solana hat das Problem nach unserer Meldung innerhalb weniger Stunden durch die Verwendung des Safemath-Mechanismus behoben. Die Korrektur ist in https://github.com/solana-labs/rbpf/pull/236 zu finden. Zum Zeitpunkt der Erstellung dieses Berichts (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/
Zeitplan
- 06.12.2021: Das Problem wurde dem Solana-Sicherheitsteam gemeldet
- 06.12.2021: Die Schwachstelle wurde behoben.
- 30.12.2021: Die Informationen zu dieser Schwachstelle wurden veröffentlicht
- 28.01.2022: Die CVE-2021–46102 wurde zugewiesen
