Desenvolvedores do proxecto Chromium 912 vulnerabilidades críticas e de alto risco identificadas en versións estables de Chrome desde 2015 e concluíron que o 70 % delas foron causadas pola inseguridade da memoria (erros ao traballar con punteiros en código C/C++). A metade destes problemas (36.1%) son causados por accesos ao búfer despois de liberar a memoria asociada a el (use-after-free).
Ao deseñar Chromium foi inicialmente , que é posible que aparezan erros no código, polo que se fixo gran énfase no uso do illamento sandbox para limitar as consecuencias das vulnerabilidades. Actualmente, as posibilidades de uso desta tecnoloxía chegaron ao límite das súas capacidades e unha maior fragmentación en procesos é impracticable desde o punto de vista do consumo de recursos.
Para manter a seguridade da base de código, Google tamén aplica "", segundo o cal calquera código engadido non debe cumprir máis de dúas das tres condicións: traballar con datos de entrada non validados, usar unha linguaxe de programación insegura (C/C++) e executar con privilexios elevados. Esta regra implica que o código para procesar datos externos debe ser reducido a privilexios mínimos (illado) ou escrito nunha linguaxe de programación segura.
Para mellorar aínda máis a seguridade da base de código, lanzouse un proxecto para evitar que aparezan erros de memoria na base de código. Hai tres enfoques principais: crear bibliotecas C++ con funcións para o funcionamento seguro da memoria e ampliar o alcance do colector de lixo, utilizando mecanismos de protección de hardware. (Memory Tagging Extension) e compoñentes de escritura en linguaxes que garanten un traballo seguro coa memoria (Java, Kotlin, JavaScript, Rust, Swift).
Espérase que o traballo se concentre en dúas áreas:
- Cambio significativo no proceso de desenvolvemento de C++, que non exclúe un impacto negativo no rendemento (comprobacións de límites adicionais e recollida de lixo). En lugar de punteiros en bruto, proponse utilizar o tipo , que permite reducir os erros explotables de uso despois de libre a fallos que non supoñen unha ameaza para a seguridade, sen un impacto negativo notable no rendemento, consumo de memoria e estabilidade.
- O uso de linguaxes deseñadas para realizar comprobacións de seguridade da memoria no momento da compilación (eliminará o impacto negativo sobre o rendemento inherente a tales comprobacións durante a execución do código, pero suporá custos adicionais para organizar a interacción do código nunha linguaxe nova co código en C++).
Usar bibliotecas seguras para a memoria é a forma máis sinxela, pero tamén menos eficiente. Reescribir código en Rust é a forma máis eficaz, pero tamén moi cara.
Fonte: opennet.ru