Almost a quarter of Android 13 is written in Rust

Rust android 13

Android 13 is the first version of Android where most of the new code added to the version is in a memory-safe language.

Through a blog post, Google engineers released the summary of the first results of the introduction Rust development support on Android.

An Android 13, about 21% of new code compiled The aggregate is written in Rust and 79% in C/C++, being the AOSP (Android Open Source Project) repository, which develops the source code for the Android platform, which has approximately 1,5 million lines of Rust code.

The code provided by AOSP it is related to new components such as the Keystore2 cryptographic keystore, the stack for UWB (Ultra-Wideband) chips, implementation of the DNS protocol over HTTP3, AVF virtualization framework (Android Virtualization Framework), experimental stacks for Bluetooth and Wi-Fi.

Online with the strategy adopted above to reduce the risk of memory error vulnerabilities, Until now Rust has been used mainly for the development of new code and to gradually strengthen the security of the most vulnerable and vital software components.

As the number of new memory-insecure code entering Android has decreased, the number of memory security vulnerabilities has also decreased. From 2019 to 2022, it dropped from 76% to 35% of total Android vulnerabilities. 2022 marks the first year that memory security vulnerabilities do not account for the majority of Android vulnerabilities.

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 bugs in it is done by using fuzzing tests, static analysis, and the use of similar techniques. to the use of 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) memory, GWP-ASAN and KFENCE.

Regarding statistics on the nature of the vulnerabilities on the Android platform, it is observed that as decreases the amount of new code that works with memory in insecure ways, it also decreases the number of vulnerabilities caused by errors when working with memory.

For example, the proportion of vulnerabilities caused by memory issues decreased from 76% in 2019 to 35% in 2022. In absolute numbers, 223 memory-related vulnerabilities were identified in 2019, 150 in 2020, 100 in 2021, and 85 in 2022 they were not found). 2022 was the first year that memory-related vulnerabilities ceased to dominate.

To date, no memory security vulnerabilities have been discovered in Android Rust code.

We don't expect that number to stay at zero forever, but given the volume of new Rust code across two versions of Android and the security-sensitive components where it's used, it's a significant result. It shows that Rust is serving its intended purpose of preventing the most common source of Android vulnerabilities.

Given that memory-related vulnerabilities are often the most dangerous, overall statistics also show a decrease in the number of critical issues and issues that can be exploited remotely. At the same time, the dynamics of detection of vulnerabilities not related to working with memory has been at approximately the same level for the last 4 years - 20 vulnerabilities per month.

The ratio of dangerous issues to vulnerabilities caused by memory errors is also the same (but as the number of 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 in an insecure manner and the number of memory-related vulnerabilities (buffer overflows, access to already freed memory, etc.).

This observation confirm the assumption of that the main attention in the implementation of secure programming techniques it should be given to the new code and not to rewrite the existing one, since most of the identified vulnerabilities are in the new code.

Source: https://security.googleblog.com/


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.