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.
Por meio de uma postagem no blog, os engenheiros do Google divulgou o resumo dos primeiros resultados da introdução Suporte ao desenvolvimento Rust no Android.
Um Android 13, cerca de 21% do novo código compilado O agregado é 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ão de linhas de código Rust.
O código fornecido pela AOSP está relacionado a novos componentes como o keystore criptográfico Keystore2, a pilha para chips UWB (Ultra-Wideband), implementação do protocolo DNS sobre HTTP3, framework de virtualização AVF (Android Virtualization Framework), stacks experimentais para Bluetooth e Wi-Fi.
On-line com a estratégia adotada acima para reduzir o risco de vulnerabilidades de erro 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 transferir toda a plataforma para Rust não está definido, e o código antigo permanece em C/C++, e o combate a bugs nele é feito por meio de testes fuzzing, análise estática e uso de técnicas semelhantes. uso do tipo MiraclePtr (ligação sobre ponteiros brutos, que executa verificações adicionais para acessar á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.
Em relação às estatísticas sobre a natureza as vulnerabilidades na plataforma Android, observa-se que conforme diminui a quantidade de novo código que funciona 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 encontrados). 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.
Dado que 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 confirmar a suposição de que a principal atenção no implementação de técnicas de programação segura deve ser dado ao novo código e não para reescrever o existente, já que a maioria das vulnerabilidades identificadas estão no novo código.
fonte: https://security.googleblog.com/