Segundo informações do engenheiros do Google, quase um quarto do Android 13 é escrito em Rust, uma linguagem segura para a memória.
Por meio de uma postagem no blog, os engenheiros do Google divulgaram o resumo dos primeiros resultados da introdução do suporte ao desenvolvedor Rust no Android.
Com isso, o Android 13 é a primeira versão do Android em que a maior parte do novo código adicionado à versão está em uma linguagem segura para a memória.
Quase um quarto do Android 13 é escrito em Rust, diz o Google
No Android 13, cerca de 21% do novo código compilado adicionado é escrito em Rust e 79% em C/C++, sendo o repositório AOSP (Android Open Source Project), que desenvolve o código-fonte para a plataforma Android, que possui aproximadamente 1,5 milhões de linhas de código Rust.
O código fornecido pelo AOSP está relacionado a novos componentes, como o armazenamento de chaves criptográficas Keystore2, a pilha para chips UWB (Ultra-Wideband), implementação do protocolo DNS sobre HTTP3, framework de virtualização AVF (Android Virtualization Framework), pilhas experimentais para Bluetooth e Wi-Fi.
Alinhado com a estratégia adotada anteriormente para reduzir o risco de vulnerabilidades de bugs de memória, até agora o Rust tem sido usado principalmente para o desenvolvimento de novos códigos e para fortalecer gradualmente a segurança dos componentes de software mais vulneráveis e vitais.
“Como o número de novos códigos inseguros de memória inseridos no Android diminuiu, o número de vulnerabilidades de segurança de memória também diminuiu. De 2019 a 2022, caiu de 76% para 35% do total de vulnerabilidades do Android. 2022 marca o primeiro ano em que as vulnerabilidades de segurança de memória não representam a maioria das vulnerabilidades do Android.”
O objetivo geral de portar toda a plataforma para Rust não está definido e o código antigo permanece em C/C++, e o combate aos erros nele é feito por meio do uso de testes de fuzzing, análise estática e uso de técnicas semelhantes ao uso do tipo MiraclePtr (binding over raw pointers, que realiza verificações adicionais para acesso a áreas de memória liberadas), o Sistema de alocação de memória Scudo (um substituto seguro para malloc/free) e mecanismos de detecção de erros ao trabalhar com memória HWAsan (Hardware Assisted AddressSanitizer), GWP-ASAN e KFENCE.
Observando as estatísticas sobre a natureza das vulnerabilidades na plataforma Android, observa-se que, à medida que diminui a quantidade de novos códigos que funcionam com a memória de maneiras inseguras, também diminui o número de vulnerabilidades causadas por erros ao trabalhar com memória.
Por exemplo, a proporção de vulnerabilidades causadas por problemas de memória diminuiu de 76% em 2019 para 35% em 2022.
Em números absolutos, 223 vulnerabilidades relacionadas à memória foram identificadas em 2019, 150 em 2020, 100 em 2021 e 85 em 2022 não foram encontradas). 2022 foi o primeiro ano em que as vulnerabilidades relacionadas à memória deixaram de dominar.
“Até o momento, nenhuma vulnerabilidade de segurança de memória foi descoberta no código Android Rust.”
“Não esperamos que esse número fique em zero para sempre, mas dado o volume do novo código Rust em duas versões do Android e os componentes sensíveis à segurança onde é usado, é um resultado significativo. Isso mostra que o Rust está cumprindo seu objetivo de prevenir a fonte mais comum de vulnerabilidades do Android.”
Como as vulnerabilidades relacionadas à memória costumam ser as mais perigosas, as estatísticas gerais também mostram uma diminuição no número de problemas críticos e problemas que podem ser explorados remotamente.
Ao mesmo tempo, a dinâmica de detecção de vulnerabilidades não relacionadas ao trabalho com memória está aproximadamente no mesmo nível nos últimos 4 anos – 20 vulnerabilidades por mês.
A proporção de problemas perigosos para vulnerabilidades causadas por erros de memória também é a mesma (mas conforme o número de vulnerabilidades diminui, o número de problemas perigosos também diminui).
As estatísticas também rastreiam a correlação entre a quantidade de novos códigos que funcionam com a memória de maneira insegura e o número de vulnerabilidades relacionadas à memória (estouros de buffer, acesso à memória já liberada, etc.).
Esta observação confirma a suposição de que a atenção principal na implementação de técnicas de programação segura deve ser dada ao novo código e não à reescrita do código existente, uma vez que a maioria das vulnerabilidades identificadas está no novo código.
