Desenvolvedores do projeto Chromium 912 vulnerabilidades críticas e de alto risco identificadas em versões estáveis do Chrome desde 2015, e concluiu que 70% delas foram causadas por insegurança de memória (erros ao trabalhar com ponteiros em código C/C++). Metade destes problemas (36.1%) são causados por acessos ao buffer após liberação da memória a ele associada (use-after-free).
Ao projetar o Chromium, foi inicialmente , que é possível que erros apareçam no código, por isso foi dada grande ênfase ao uso do isolamento de sandbox para limitar as consequências das vulnerabilidades. Atualmente, as possibilidades de utilização desta tecnologia atingiram o limite de suas capacidades e uma maior fragmentação em processos é inviável do ponto de vista do consumo de recursos.
Para manter a segurança da base de código, o Google também impõe "“, segundo o qual qualquer código adicionado não deve atender a mais do que duas das três condições: trabalhar com dados de entrada não validados, usar uma linguagem de programação insegura (C/C++) e executar com privilégios elevados. Esta regra implica que o código para processamento de dados externos deve ser reduzido a privilégios mínimos (isolado) ou escrito em uma linguagem de programação segura.
Para aumentar ainda mais a segurança da base de código, foi lançado um projeto para evitar o aparecimento de erros de memória na base de código. Existem três abordagens principais: criar bibliotecas C++ com funções para operação segura da memória e ampliar o escopo do coletor de lixo, utilizando mecanismos de proteção de hardware (Memory Tagging Extension) e escrever componentes em linguagens que garantem trabalho seguro com memória (Java, Kotlin, JavaScript, Rust, Swift).
Espera-se que o trabalho se concentre em duas áreas:
- Mudança significativa no processo de desenvolvimento C++, que não exclui um impacto negativo no desempenho (verificações adicionais de limites e coleta de lixo). Em vez de ponteiros brutos, propõe-se usar o tipo , que permite reduzir erros exploráveis de uso após liberação a falhas que não representam uma ameaça à segurança, sem um impacto negativo perceptível no desempenho, no consumo de memória e na estabilidade.
- O uso de linguagens projetadas para realizar verificações de segurança de memória em tempo de compilação (eliminará o impacto negativo no desempenho inerente a tais verificações durante a execução do código, mas levará a custos adicionais para organizar a interação do código em uma nova linguagem com o código em C++).
Usar bibliotecas com segurança de memória é a maneira mais simples, mas também menos eficiente. Reescrever código em Rust é classificado como a forma mais eficaz, mas também muito cara.
Fonte: opennet.ru