Android 13 is de eerste versie van Android waarbij de meeste nieuwe code die aan de versie is toegevoegd, in een geheugenveilige taal is.
Via een blogpost, Google-ingenieurs heeft de samenvatting van de eerste resultaten vrijgegeven van de introductie Rust-ontwikkelingsondersteuning op Android.
Een Android 13, ongeveer 21% van de nieuwe code gecompileerd Het aggregaat is geschreven in Rust en 79% in C/C++, zijnde de AOSP (Android Open Source Project) repository, die de broncode ontwikkelt voor het Android-platform, dat ongeveer 1,5 miljoen regels Rust-code heeft.
De code geleverd door AOSP het is gerelateerd aan nieuwe componenten zoals de Keystore2 cryptografische keystore, de stack voor UWB (Ultra-Wideband) chips, implementatie van het DNS-protocol via HTTP3, AVF virtualisatie framework (Android Virtualization Framework), experimentele stacks voor Bluetooth en Wi-Fi.
In de rij met de hierboven aangenomen strategie om het risico op kwetsbaarheden voor geheugenfouten te verminderen, Tot nu toe werd Rust vooral gebruikt voor het ontwikkelen van nieuwe code en het stapsgewijs versterken van de beveiliging van de meest kwetsbare en vitale softwarecomponenten.
Naarmate het aantal nieuwe geheugenonveilige code dat Android binnenkomt, is afgenomen, is ook het aantal geheugenbeveiligingsproblemen afgenomen. Van 2019 tot 2022 daalde het van 76% naar 35% van de totale Android-kwetsbaarheden. 2022 is het eerste jaar dat kwetsbaarheden in de geheugenbeveiliging niet verantwoordelijk zijn voor de meeste Android-kwetsbaarheden.
Het algemene doel van het overbrengen van het hele platform naar Rust is niet vastgesteld, en de oude code blijft in C/C++, en de strijd tegen bugs daarin wordt gedaan door gebruik te maken van fuzzing-tests, statische analyse en het gebruik van vergelijkbare technieken. gebruik van het MiraclePtr-type (binden over onbewerkte aanwijzers, die extra controles uitvoert voor toegang tot vrijgekomen geheugengebieden), het Scudo-geheugentoewijzingssysteem (een veilige vervanging voor malloc/free) en foutdetectiemechanismen bij het werken met HWAsan-geheugen (Hardware Assisted AddressSanitizer) , GWP-ASAN en KFENCE.
Met betrekking tot statistieken over de aard van de kwetsbaarheden op het Android-platform wordt opgemerkt dat as vermindert de hoeveelheid nieuwe code die op onveilige manieren met geheugen werkt, vermindert het ook het aantal kwetsbaarheden veroorzaakt door fouten bij het werken met geheugen.
Zo daalde het aandeel kwetsbaarheden veroorzaakt door geheugenproblemen van 76% in 2019 naar 35% in 2022. In absolute aantallen werden 223 geheugengerelateerde kwetsbaarheden geïdentificeerd in 2019, 150 in 2020, 100 in 2021 en 85 in 2022. werden niet gevonden). 2022 was het eerste jaar dat geheugengerelateerde kwetsbaarheden niet meer domineerden.
Tot op heden zijn er geen geheugenbeveiligingsproblemen ontdekt in de Android Rust-code.
We verwachten niet dat dat aantal voor altijd op nul zal blijven, maar gezien het volume van nieuwe Rust-code in twee versies van Android en de beveiligingsgevoelige componenten waar het wordt gebruikt, is het een significant resultaat. Het laat zien dat Rust zijn beoogde doel dient om de meest voorkomende bron van Android-kwetsbaarheden te voorkomen.
Aangezien geheugengerelateerde kwetsbaarheden zijn vaak het gevaarlijkst, tonen algemene statistieken ook een afname van het aantal kritieke problemen en problemen die op afstand kunnen worden misbruikt. Tegelijkertijd is de dynamiek van de detectie van kwetsbaarheden die geen verband houden met het werken met geheugen de afgelopen 4 jaar op ongeveer hetzelfde niveau geweest - 20 kwetsbaarheden per maand.
De verhouding tussen gevaarlijke problemen en kwetsbaarheden veroorzaakt door geheugenfouten is ook hetzelfde (maar naarmate het aantal kwetsbaarheden afneemt, neemt ook het aantal gevaarlijke problemen af).
De statistieken volgen ook de correlatie tussen de hoeveelheid nieuwe code die op een onveilige manier met geheugen werkt en het aantal geheugengerelateerde kwetsbaarheden (bufferoverflows, toegang tot reeds vrijgemaakt geheugen, enz.).
Deze waarneming bevestigen de veronderstelling van dat de belangrijkste aandacht in de implementatie van veilige programmeertechnieken het moet aan de nieuwe code worden gegeven en niet om de bestaande te herschrijven, aangezien de meeste van de geïdentificeerde kwetsbaarheden in de nieuwe code zitten.
bron: https://security.googleblog.com/