Ingenieure von Google fassten die ersten Ergebnisse der Einführung der Unterstützung für die Entwicklung in der Rust-Sprache in der Android-Plattform zusammen. In Android 13 sind etwa 21 % des neu hinzugefügten kompilierten Codes in Rust und 79 % in C/C++ geschrieben. Das AOSP-Repository (Android Open Source Project), das den Quellcode der Android-Plattform entwickelt, enthält etwa 1.5 Millionen Zeilen Rust-Code, der mit neuen Komponenten wie dem kryptografischen Schlüsselspeicher Keystore2, einem Stack für UWB-Chips (Ultra-Wideband), verknüpft ist. , Implementierung des DNS-over-HTTP3-Protokolls, des Virtualisierungsframeworks AVF (Android Virtualization Framework), experimentelle Stacks für Bluetooth und Wi-Fi.
In Übereinstimmung mit der zuvor angenommenen Strategie, das Risiko von Schwachstellen zu verringern, die durch Fehler bei der Arbeit mit dem Speicher verursacht werden, wird die Rust-Sprache derzeit hauptsächlich bei der Entwicklung von neuem Code und zur schrittweisen Stärkung der Sicherheit der anfälligsten und wichtigsten Softwarekomponenten verwendet. Es gibt kein allgemeines Ziel, die gesamte Plattform auf Rust zu übertragen, und der alte Code verbleibt in C/C++, und die Fehlerbekämpfung darin erfolgt durch den Einsatz von Fuzzing-Tests, statischer Analyse und der Verwendung ähnlicher Techniken in der Entwicklung Verwendung des MiraclePtr-Typs (Bindung über Rohzeiger, Durchführung zusätzlicher Prüfungen für den Zugriff auf freigegebene Speicherbereiche), des Scudo-Speicherzuordnungssystems (ein sicherer Ersatz für malloc/free) und Fehlererkennungsmechanismen bei der Arbeit mit Speicher HWAsan (Hardware-unterstützter AddressSanitizer), GWP-ASAN und KFENCE.
Was die Statistiken zur Art der Schwachstellen in der Android-Plattform betrifft, so wird darauf hingewiesen, dass mit der Abnahme neuer Codes, die unsicher mit dem Speicher arbeiten, auch die Anzahl der Schwachstellen abnimmt, die durch Fehler bei der Arbeit mit dem Speicher verursacht werden. Beispielsweise sank der Anteil der durch Speicherprobleme verursachten Schwachstellen von 76 % im Jahr 2019 auf 35 % im Jahr 2022. In absoluten Zahlen wurden 2019 223 speicherbezogene Schwachstellen identifiziert, 2020 im Jahr 150, 2021 im Jahr 100 und 2022 im Jahr 85 (alle festgestellten Schwachstellen befanden sich im C/C++-Code; im Rust-Code gab es bisher keine ähnlichen Probleme). gefunden). 2022 war das erste Jahr, in dem speicherbezogene Schwachstellen nicht mehr im Vordergrund standen.
Da speicherbezogene Schwachstellen in der Regel die gefährlichsten sind, zeigen die Gesamtstatistiken auch einen Rückgang der Anzahl kritischer Probleme und Probleme, die aus der Ferne ausgenutzt werden können. Gleichzeitig ist die Dynamik der Identifizierung von Schwachstellen, die nicht mit der Arbeit mit dem Speicher zusammenhängen, in den letzten 4 Jahren ungefähr auf dem gleichen Niveau geblieben – 20 Schwachstellen pro Monat. Der Anteil gefährlicher Probleme unter den Schwachstellen, die durch Fehler bei der Arbeit mit dem Speicher verursacht werden, bleibt ebenfalls bestehen (aber da die Zahl solcher Schwachstellen abnimmt, nimmt auch die Zahl gefährlicher Probleme ab).
Die Statistiken verfolgen auch die Korrelation zwischen der Menge an neuem Code, der unsicher mit dem Speicher arbeitet, und der Anzahl speicherbezogener Schwachstellen (Pufferüberläufe, Zugriff auf bereits freigegebenen Speicher usw.). Diese Beobachtung bestätigt die Annahme, dass der Schwerpunkt bei der Implementierung sicherer Programmiertechniken auf dem Entfernen von neuem Code und nicht auf dem Umschreiben von bestehendem Code liegen sollte, da der Großteil der identifizierten Schwachstellen in neuem Code liegt.
Source: opennet.ru