Android 13 es la primera versión de Android en la que la mayoría del código nuevo agregado a la versión está en un lenguaje seguro para la memoria.

Mediante una publicación de blog, los ingenieros de Google dieron a conocer el resumen de los primeros resultados de la introducción del soporte de desarrollo de Rust en Android.

En Android 13, aproximadamente el 21 % del nuevo código compilado agregado está escrito en Rust y el 79 % en C/C++, siendo el repositorio de AOSP (Android Open Source Project), que desarrolla el código fuente de la plataforma Android, que tiene aproximadamente 1,5 millones de líneas de código Rust.

El código proporcionado por AOSP está relacionado con nuevos componentes como el almacén de claves criptográficas Keystore2, la pila para chips UWB ( Ultra-Wideband ) , implementación del protocolo DNS sobre HTTP3, marco de virtualización AVF (Android Virtualization Framework), pilas experimentales para Bluetooth y Wi-Fi.

En línea con la estrategia adoptada anteriormente para reducir el riesgo de vulnerabilidades de errores de memoria, hasta ahora Rust se ha utilizado principalmente para el desarrollo de código nuevo y para reforzar gradualmente la seguridad de los componentes de software más vulnerables y vitales.

A medida que ha disminuido la cantidad de nuevos códigos no seguros para la memoria que ingresan a Android, también ha disminuido la cantidad de vulnerabilidades de seguridad de la memoria. De 2019 a 2022, se redujo del 76 % al 35 % de las vulnerabilidades totales de Android. 2022 es el primer año en el que las vulnerabilidades de seguridad de la memoria no representan la mayoría de las vulnerabilidades de Android .

El objetivo general de transferir toda la plataforma a Rust no está establecido, y el código antiguo permanece en C/C++, y la lucha contra los errores en él se realiza mediante el uso de pruebas de fuzzing, análisis estático y el uso de técnicas similares al uso del tipo MiraclePtr (enlace sobre punteros sin formato, que realiza comprobaciones adicionales para acceder a áreas de memoria liberadas), el sistema de asignación de memoria Scudo (un reemplazo seguro para malloc/free) y mecanismos de detección de errores cuando se trabaja con memoria HWAsan(AddressSanitizer asistido por hardware), GWP-ASAN y KFENCE.

En cuanto a las estadísticas sobre la naturaleza de las vulnerabilidades en la plataforma Android, se observa que a medida que disminuye la cantidad de código nuevo que funciona con la memoria de manera insegura, también disminuye la cantidad de vulnerabilidades causadas por errores al trabajar con la memoria.

Por ejemplo, la proporción de vulnerabilidades causadas por problemas de memoria disminuyó del 76 % en 2019 al 35 % en 2022. En números absolutos, se identificaron 223 vulnerabilidades relacionadas con la memoria en 2019, 150 en 2020, 100 en 2021 y 85 en 2022 no se encontraron). 2022 fue el primer año en el que las vulnerabilidades relacionadas con la memoria dejaron de dominar.

Hasta la fecha, no se han descubierto vulnerabilidades de seguridad de memoria en el código Rust de Android.

No esperamos que ese número permanezca en cero para siempre, pero dado el volumen del nuevo código Rust en dos versiones de Android y los componentes sensibles a la seguridad donde se usa, es un resultado significativo. Demuestra que Rust está cumpliendo su propósito previsto de prevenir la fuente más común de vulnerabilidades de Android.

Dado que las vulnerabilidades relacionadas con la memoria suelen ser las más peligrosas, las estadísticas generales también muestran una disminución en la cantidad de problemas críticos y problemas que pueden explotarse de forma remota. Al mismo tiempo, la dinámica de detección de vulnerabilidades no relacionadas con el trabajo con memoria se ha mantenido aproximadamente en el mismo nivel durante los últimos 4 años: 20 vulnerabilidades por mes.

La proporción de problemas peligrosos entre las vulnerabilidades causadas por errores de memoria también se mantiene (pero a medida que disminuye la cantidad de vulnerabilidades, también disminuye la cantidad de problemas peligrosos).

Las estadísticas también rastrean la correlación entre la cantidad de código nuevo que funciona con la memoria de manera insegura y la cantidad de vulnerabilidades relacionadas con la memoria (desbordamientos de búfer, acceso a memoria ya liberada, etc.).

Esta observación confirma la suposición de que la atención principal en la implementación de técnicas de programación segura debe darse al código nuevo y no a reescribir el existente, ya que la mayor parte de las vulnerabilidades identificadas están en el código nuevo.

Fuente: https://security.googleblog.com/