O Google revelou que a mudança para linguagens seguras de memória, como Rust, como parte de sua abordagem segura por design, resultou na queda da porcentagem de vulnerabilidades de segurança de memória detectadas no Android de 76% para 24% em um período de seis anos. .
A gigante da tecnologia disse que o foco do Safe Coding em novos recursos não apenas reduz os riscos de segurança da base de código, mas também torna as substituições “maiores e mais econômicas”.
Em última análise, isso leva a uma diminuição nos riscos de segurança da memória, à medida que novas atualizações de memória inseguras ficam mais lentas depois de um tempo e novas atualizações de segurança de memória assumem o controle, disseram Jeff Vander Stoep e Alex Rebert do Google em uma postagem compartilhada com Hacker News.
Talvez o mais interessante seja que o número de vulnerabilidades de segurança de memória pode diminuir apesar do aumento no número de novos códigos seguros de memória.
O paradoxo é explicado pelo facto de as vulnerabilidades serem altamente decompostas, com a investigação a concluir que o maior número de vulnerabilidades tende a residir em código novo ou recentemente modificado.
“O problema é muito maior com o novo código, que exige uma mudança fundamental na forma como construímos códigos”, observam Vander Stoep e Rebert. “O código amadurece e se torna mais seguro com o tempo, de forma incremental, fazendo com que o retorno do investimento, como a reescrita, diminua com o tempo, à medida que o código cresce.”
O Google, que anunciou oficialmente seus planos de oferecer suporte à linguagem de programação Rust no Android em abril de 2021, disse que começou a priorizar a transição de novos desenvolvimentos para linguagens seguras de memória em 2019.
Como resultado, o número de vulnerabilidades de segurança de memória detectadas no sistema operacional diminuiu de 223 em 2019 para menos de 50 em 2024.
Também é desnecessário dizer que uma redução significativa de tais erros depende do desenvolvimento de métodos destinados a combatê-los, desde a captura ativa até a mitigação ativa e a descoberta de vulnerabilidades usando ferramentas como os desinfetantes do Clang.
A gigante da tecnologia também observou que as estratégias de segurança de memória devem evoluir ainda mais para priorizar a “prevenção de alta garantia”, incorporando princípios de segurança desde o design que incluem a segurança em seu núcleo.
“Em vez de focar nas intervenções utilizadas (mitigação, ofuscação) ou tentar usar o desempenho passado para prever a segurança futura, o Secure Code nos permite fazer afirmações fortes sobre as propriedades do código e o que pode ou não acontecer com base nessas propriedades”, Vander . Roberto parou.
Não termina aí. O Google disse que também está focado em fornecer interoperabilidade entre Rust, C++ e Kotlin, em vez de reescrever o código, como uma “maneira eficaz e escalonável” de adotar linguagens seguras de memória e, eventualmente, eliminar todas as classes de vulnerabilidades.
“A adoção da codificação segura para novos códigos proporciona uma mudança de paradigma, permitindo-nos usar a decomposição de risco inerente a nosso favor, mesmo em grandes sistemas existentes”, afirmou.
“A ideia é simples: se fecharmos a torneira de novas vulnerabilidades, elas se tornarão menos comuns, tornarão todo o nosso código mais seguro, aumentarão a eficiência do design de segurança e aliviarão os desafios de robustez associados às técnicas de segurança de memória existentes para que possam ser usado de forma eficaz como pretendido.”
Este desenvolvimento ocorre no momento em que o Google propõe colaboração adicional com as equipes de engenharia de segurança de produto e unidade de processamento gráfico (GPU) da Arm para sinalizar múltiplas vulnerabilidades e melhorar a segurança geral da pilha de software/firmware GPU no ecossistema Android.
Isso inclui a descoberta de dois problemas de memória no código do driver de personalização do Pixel (CVE-2023-48409 e CVE-2023-48421) e um no firmware da GPU Arm Valhall e no firmware da arquitetura da GPU de 5ª geração (CVE -2024-0153).
“O teste ativo é uma boa higiene, pois pode levar à descoberta e resolução de novas vulnerabilidades antes que sejam exploradas”, disseram Google e Arm.
