Engineers at Google have drawn initial conclusions regarding the implementation of Rust support in the Android platform. In Android 13, approximately 21% of the newly added compileable code is written in Rust, while 79% is in C/C++. The AOSP (Android Open Source Project) repository contains about 1.5 million lines of code in Rust, associated with new components such as the Keystore2 cryptographic key storage, the UWB (Ultra-Wideband) chip stack, the DNS-over-HTTP3 protocol implementation, the AVF (Android Virtualization Framework), and experimental stacks for Bluetooth and Wi-Fi.
In line with the previously adopted strategy to reduce the risk of vulnerabilities caused by memory handling errors, Rust is currently mainly used for developing new code and gradually enhancing the security of the most vulnerable and critical software components. There is no overarching goal to transition the entire platform to Rust, and legacy code remains in C/C++, while error resolution is managed through techniques like fuzz testing, static analysis, and methods similar to MiraclePtr (a wrapper over raw pointers that performs additional checks for accessing freed memory areas), the Scudo memory allocator (a safe replacement for malloc/free), and memory error detection mechanisms such as HWAsan (Hardware-assisted AddressSanitizer), GWP-ASAN, and KFENCE.
Regarding statistics on the nature of vulnerabilities in the Android platform, it is noted that as unsafe memory-handling code decreases, there is also a reduction in the number of vulnerabilities caused by memory errors. For instance, the share of vulnerabilities caused by memory issues has dropped from 76% in 2019 to 35% in 2022. In absolute numbers, there were 223 memory-related vulnerabilities identified in 2019, 150 in 2020, 100 in 2021, and 85 in 2022 (all noted vulnerabilities are in C/C++ code; no similar problems have been found in Rust code thus far). The year 2022 marked the first year in which memory-related vulnerabilities ceased to dominate.
Because memory-related vulnerabilities are usually the most dangerous, there is also a noted decrease in the total number of critical issues and problems that can be exploited remotely. At the same time, the detection rate of vulnerabilities not related to memory management has remained roughly stable over the last four years, averaging about 20 vulnerabilities per month. The proportion of dangerous problems among vulnerabilities caused by memory management errors is also maintained (but as the number of such vulnerabilities decreases, so does the number of dangerous problems).
The statistics also track a correlation between the amount of new code that is unsafe in terms of memory management and the number of memory-related vulnerabilities (buffer overflows, accessing already freed memory, etc.). This observation confirms the assumption that the primary focus of introducing safe programming techniques should be on new code rather than rewriting existing code, as the majority of identified vulnerabilities pertain to new code.
Source: opennet.ru
