Android 13 ist die erste Version von Android, bei der der größte Teil des neuen Codes, der der Version hinzugefügt wurde, in einer speichersicheren Sprache vorliegt.
Durch einen Blogbeitrag, Google-Ingenieure veröffentlichte die Zusammenfassung der ersten Ergebnisse der Einleitung Rust-Entwicklungsunterstützung auf Android.
Ein Android 13, etwa 21 % des neuen Codes kompiliert Das Aggregat ist in Rust und zu 79 % in C/C++ geschrieben, wobei es sich um das AOSP-Repository (Android Open Source Project) handelt, das den Quellcode für die Android-Plattform entwickelt, die ungefähr 1,5 Millionen Zeilen Rust-Code enthält.
Der Code bereitgestellt von AOSP Es bezieht sich auf neue Komponenten wie den kryptografischen Keystore2 Keystore, den Stack für UWB (Ultra-Wideband)-Chips, die Implementierung des DNS-Protokolls über HTTP3, das AVF-Virtualisierungsframework (Android Virtualization Framework), experimentelle Stacks für Bluetooth und Wi-Fi.
In der Schlange mit der oben angenommenen Strategie, um das Risiko von Speicherfehlerschwachstellen zu verringern, Bisher wurde Rust hauptsächlich für die Entwicklung von neuem Code und zur schrittweisen Stärkung der Sicherheit der anfälligsten und wichtigsten Softwarekomponenten verwendet.
Da die Anzahl neuer speicherunsicherer Codes, die in Android eindringen, abgenommen hat, ist auch die Anzahl der Speichersicherheitslücken zurückgegangen. Von 2019 bis 2022 ist sie von 76 % auf 35 % aller Android-Schwachstellen gesunken. 2022 ist das erste Jahr, in dem Speichersicherheitslücken nicht für die Mehrheit der Android-Schwachstellen verantwortlich sind.
Das generelle Ziel, die gesamte Plattform nach Rust zu übertragen, ist nicht gesetzt, der alte Code bleibt in C/C++, und die Bekämpfung der darin enthaltenen Fehler erfolgt durch Fuzzing-Tests, statische Analyse und den Einsatz ähnlicher Techniken Verwendung des MiraclePtr-Typs (Bindung über Rohzeiger, der zusätzliche Prüfungen für den Zugriff auf freigegebene Speicherbereiche durchführt), des Scudo-Speicherzuweisungssystems (ein sicherer Ersatz für malloc/free) und Fehlererkennungsmechanismen bei der Arbeit mit HWAsan-Speicher (Hardware Assisted AddressSanitizer). , GWP-ASAN und KFENCE.
In Bezug auf Statistiken über die Art der Schwachstellen auf der Android-Plattform wird das als beobachtet verringert die Menge an neuem Code, der auf unsichere Weise mit dem Speicher arbeitet, verringert es auch die Anzahl der Schwachstellen, die durch Fehler bei der Arbeit mit dem Arbeitsspeicher verursacht werden.
So sank beispielsweise der Anteil der durch Speicherprobleme verursachten Schwachstellen von 76 % im Jahr 2019 auf 35 % im Jahr 2022. In absoluten Zahlen wurden 223 speicherbezogene Schwachstellen im Jahr 2019, 150 im Jahr 2020, 100 im Jahr 2021 und 85 im Jahr 2022 identifiziert wurden nicht gefunden). 2022 war das erste Jahr, in dem speicherbezogene Schwachstellen aufhörten zu dominieren.
Bisher wurden keine Speichersicherheitslücken im Android-Rust-Code entdeckt.
Wir erwarten nicht, dass diese Zahl für immer bei Null bleibt, aber angesichts der Menge an neuem Rust-Code in zwei Android-Versionen und den sicherheitsrelevanten Komponenten, in denen er verwendet wird, ist dies ein signifikantes Ergebnis. Es zeigt, dass Rust seinen beabsichtigten Zweck erfüllt, die häufigste Quelle von Android-Schwachstellen zu verhindern.
Da Sicherheitslücken im Zusammenhang mit dem Arbeitsspeicher sind oft die gefährlichsten, zeigen die Gesamtstatistiken auch einen Rückgang der Anzahl kritischer Probleme und Probleme, die aus der Ferne ausgenutzt werden können. Gleichzeitig war die Dynamik der Erkennung von Schwachstellen, die nicht mit der Arbeit mit dem Speicher zusammenhängen, in den letzten 4 Jahren ungefähr auf dem gleichen Niveau - 20 Schwachstellen pro Monat.
Das Verhältnis von gefährlichen Problemen zu Schwachstellen, die durch Speicherfehler verursacht werden, ist ebenfalls gleich (aber wenn die Anzahl der Schwachstellen abnimmt, nimmt auch die Anzahl gefährlicher Probleme ab).
Die Statistik verfolgt auch die Korrelation zwischen der Menge an neuem Code, der auf unsichere Weise mit dem Speicher arbeitet, und der Anzahl der speicherbezogenen Schwachstellen (Pufferüberläufe, Zugriff auf bereits freigegebenen Speicher usw.).
Diese Beobachtung bestätigen die Vermutung dass die Hauptaufmerksamkeit in der Implementierung sicherer Programmiertechniken Es sollte dem neuen Code gegeben werden und nicht den bestehenden umzuschreiben, da die meisten der identifizierten Schwachstellen im neuen Code liegen.
Quelle: https://security.googleblog.com/