Engineers from Google summed up the first results of the introduction of Rust development support into the Android platform. In Android 13, approximately 21% of the new compiled code added is written in Rust, and 79% in C/C++. The AOSP (Android Open Source Project) repository, which develops the source code for the Android platform, has approximately 1.5 million lines of Rust code related to new components such as the Keystore2 cryptographic key store, the stack for UWB chips (Ultra-Wideband), implementation of the DNS-over-HTTP3 protocol, AVF (Android Virtualization Framework) virtualization framework, experimental stacks for Bluetooth and Wi-Fi.
In line with the previously adopted strategy to reduce the risk of memory bug vulnerabilities, Rust has so far been used primarily for new code development and for gradually hardening the security of the most vulnerable and vital software components. The general goal of transferring the entire platform to Rust is not set and the old code remains in C / C ++, and the fight against errors in it is done through the use of fuzzing testing, static analysis and the use of techniques similar to using the MiraclePtr type (binding over raw pointers, which performs additional checks for accessing freed memory areas), the Scudo memory allocation system (a safe replacement for malloc / free) and error detection mechanisms when working with HWAsan (Hardware-assisted AddressSanitizer), GWP-ASAN and KFENCE memory.
As for the statistics on the nature of vulnerabilities in the Android platform, it is noted that as the number of new code that works with memory unsafely decreases, there is also a decrease in the number of vulnerabilities caused by errors when working with memory. For example, the share of vulnerabilities caused by memory problems has decreased from 76% in 2019 to 35% in 2022. In absolute numbers, 2019 memory-related vulnerabilities were identified in 223, 2020 in 150, 2021 in 100, and 2022 in 85 was not found). 2022 was the first year in which memory-related vulnerabilities ceased to dominate.
Since memory-related vulnerabilities are usually the most dangerous, the overall statistics also show a decrease in the number of critical problems and problems that can be exploited remotely. At the same time, the dynamics of detection of vulnerabilities not related to working with memory has remained approximately at the same level for the last 4 years - 20 vulnerabilities per month. The share of dangerous problems among the vulnerabilities caused by errors in working with memory also remains (but as the number of such vulnerabilities decreases, the number of dangerous problems also decreases).
The statistics also track the correlation between the amount of new code that works with memory unsafely and the number of memory-related vulnerabilities (buffer overflows, access to already freed memory, etc.). This observation confirms the assumption that the main attention in the implementation of secure programming techniques should be removed to new code, and not to rewriting the existing one, since the bulk of the identified vulnerabilities are in new code.
Source: opennet.ru