Desenvolvedores do projeto Chromium 912 vulnerabilidades perigosas e críticas identificadas nas versões estáveis do Chrome desde 2015, e foi concluído que 70% delas foram causadas por manipulação insegura da memória (erros no uso de ponteiros no código em C/C++). Metade desses problemas (36,1%) é causada por acessos ao buffer após a liberação da memória associada (use-after-free).
No design do Chromium, foi originalmente , que erros no código não poderiam ser excluídos, portanto, uma grande ênfase foi colocada na aplicação da isolamento sandbox para limitar as consequências da manifestação de vulnerabilidades. Atualmente, as capacidades de aplicação desta tecnologia atingiram o limite de suas possibilidades e a fragmentação adicional em processos não é viável do ponto de vista do consumo de recursos.
Para manter a segurança da base de código, o Google também aplica a "", de acordo com a qual qualquer código adicionado deve se enquadrar em no máximo duas das três condições: trabalhar com entradas não verificadas, utilizar uma linguagem de programação insegura (C/C++) e executar com privilégios elevados. Dessa regra, deduz-se que o código para processamento de dados externos deve ser ou 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 a manifestação de erros de manipulação de memória na base de código. Três abordagens principais estão sendo destacadas: criação de bibliotecas C++ com funções para manipulação segura da memória e ampliação do escopo do coletor de lixo, aplicação de mecanismos de proteção de hardware (Memory Tagging Extension) e escrita de componentes em linguagens que garantem manipulação segura da memória (Java, Kotlin, JavaScript, Rust, Swift).
Espera-se que o trabalho esteja focado em duas direções:
- Mudança significativa do processo de desenvolvimento em C++, sem excluir a possibilidade de impacto negativo no desempenho (verificações adicionais de limites e coleta de lixo). Em vez de ponteiros raw, propõe-se o uso no código do tipo , que permite reduzir erros exploráveis do tipo use-after-free a falhas que não representam risco à segurança, sem impacto negativo significativo no desempenho, consumo de memória e estabilidade.
- A aplicação de linguagens projetadas para realizar verificações de segurança da memória durante a compilação (permitindo eliminar o impacto negativo na performance, característico de tais verificações durante a execução do código, mas levando a custos adicionais na organização da interação do código em uma nova linguagem com o código em C++).
O uso de bibliotecas para o manejo seguro da memória é a abordagem mais simples, mas menos eficaz. Reescrever o código em Rust é considerado o caminho mais eficaz, mas também muito caro.
Fonte: opennet.ru
