Desenvolvedores do proxecto Chromium Un estudo analizou 912 vulnerabilidades graves e críticas identificadas en versións estables de Chrome desde 2015, e concluíu que o 70 % delas estaban causadas por inseguridade da memoria (erros de manexo de punteiros no código C/C++). A metade destes problemas (36.1 %) estaban causados por accesos de uso despois de liberación a un búfer.
Cando se deseñou Chromium, orixinalmente foi Dado que non se poden descartar erros no código, puxéronse énfase significativa no illamento de sandbox para limitar o impacto das vulnerabilidades. Actualmente, a aplicación desta tecnoloxía chegou aos seus límites e unha maior fragmentación en procesos non é práctica desde o punto de vista do consumo de recursos.
Para manter a seguridade da súa base de código, Google tamén usa "", segundo o cal calquera código engadido non debe cumprir máis de dúas destas tres condicións: manexar datos de entrada non fiables, usar unha linguaxe de programación insegura (C/C++) e executarse con privilexios elevados. Esta regra implica que o código para procesar datos externos debe reducirse aos privilexios mínimos (illarse) ou escribirse nunha linguaxe de programación segura.
Para reforzar 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. Estanse a seguir tres enfoques principais: crear bibliotecas C++ con funcións para a xestión segura da memoria, ampliar o alcance do colector de lixo e usar mecanismos de protección de hardware. (Extensión de etiquetado de memoria) e escribindo compoñentes en linguaxes que proporcionan seguridade de memoria (Java, Kotlin, JavaScript, Rust, Swift).
Espérase que o traballo se centre en dúas áreas:
- Un cambio significativo no proceso de desenvolvemento de C++, que pode ter un impacto negativo no rendemento (comprobación adicional de límites e recollida de lixo). En lugar de punteiros brutos, proponse usar o tipo no código , o que permite reducir os erros de uso despois da liberación explotables a fallos que non supoñen unha ameaza para a seguridade, sen un impacto negativo perceptible no rendemento, o consumo de memoria e a estabilidade.
- Empregar linguaxes deseñadas para realizar comprobacións de seguridade da memoria en tempo de compilación eliminará o impacto negativo no rendemento inherente a tales comprobacións en tempo de execución, pero levará a custos adicionais para organizar a interacción do código na nova linguaxe co código en C++.
Empregar bibliotecas con memoria segura é o enfoque máis sinxelo, pero tamén o menos efectivo. Reescribir o código en Rust considérase o máis efectivo, pero tamén o máis caro.
Fonte: opennet.ru
