El 70% de los problemas de seguridad en Chromium son causados por errores en la gestión de la memoria.

Los desarrolladores del proyecto Chromium analizaron Se identificaron 912 vulnerabilidades peligrosas y críticas en las versiones estables de Chrome desde 2015, y se llegó a la conclusión de que el 70% de ellas fueron provocadas por un manejo inseguro de la memoria (errores al trabajar con punteros en código C/C++). La mitad de estos problemas (36.1%) fueron causados por accesos a un búfer después de liberar la memoria asociada (use-after-free).

Al diseñar Chromium, se consideró desde un inicio que en el código podrían surgir errores, por lo que se apostó fuertemente por la aplicación de la aislación sandbox para limitar las consecuencias de las vulnerabilidades. En la actualidad, las capacidades de aplicación de esta tecnología han alcanzado el límite de su potencial y fragmentar aún más en procesos es poco práctico en términos de consumo de recursos.Para mantener la seguridad de la base de código, Google también aplica la "

regla de dos", de acuerdo con la cual cualquier código que se añada debe cumplir no más de dos condiciones de tres: trabajar con datos de entrada no verificados, utilizar un lenguaje de programación inseguro (C/C++) y ejecutarse con privilegios elevados. De esta regla se desprende que el código para el manejo de datos externos debe ser recortado a privilegios mínimos (aislado) o debe ser escrito en un lenguaje de programación seguro.Para fortalecer aún más la seguridad de la base de código, se ha lanzado un proyecto para prevenir la aparición de errores en el manejo de la memoria en la base de código. Se destacan tres enfoques principales: la creación de bibliotecas C++ con funciones para un manejo seguro de la memoria y la expansión del ámbito de aplicación del recolector de basura, la aplicación de mecanismos de protección de hardware

MTE (Memory Tagging Extension) y la escritura de componentes en lenguajes que aseguran un manejo seguro de la memoria (Java, Kotlin, JavaScript, Rust, Swift). Se espera que el trabajo se concentre en dos direcciones:

Un cambio significativo en el proceso de desarrollo en C++, que no excluirá un impacto negativo en el rendimiento (verificaciones adicionales de límites y recolección de basura). En lugar de punteros raw, se propone utilizar en el código el tipo

• MiraclePtr , que permite reducir los errores explotables de tipo use-after-free a fallos que no representan una amenaza para la seguridad, sin un impacto negativo significativo en el rendimiento, el consumo de memoria y la estabilidad., lo que permite reducir los errores explotables de tipo use-after-free a fallos que no suponen una amenaza para la seguridad, sin un impacto negativo significativo en el rendimiento, consumo de memoria y estabilidad.
• El uso de lenguajes que permiten realizar verificaciones de seguridad de memoria durante la compilación (lo que evitará el impacto negativo en el rendimiento, típico de tales verificaciones durante la ejecución del código, pero conllevará costos adicionales para organizar la interacción del código en un nuevo idioma con el código en C++).

El uso de bibliotecas para el manejo seguro de la memoria es el método más sencillo, pero también el menos eficiente. Reescribir el código en Rust se considera el enfoque más eficaz, aunque también es muy costoso.

Fuente: opennet.ru