El 70% de los problemas de seguridad en Chromium se deben a errores de memoria

Desarrolladores del proyecto Chromium analizado 912 vulnerabilidades críticas y de alto riesgo identificadas en versiones estables de Chrome desde 2015, y concluyó que el 70% de ellas fueron causadas por inseguridad de la memoria (errores al trabajar con punteros en código C/C++). La mitad de estos problemas (36.1%) se deben a accesos al buffer después de liberar la memoria asociada al mismo (use-after-free).

El 70% de los problemas de seguridad en Chromium se deben a errores de memoria

Al diseñar Chromium inicialmente se acostado, que es posible que aparezcan errores en el código, por lo que se puso gran énfasis en el uso del aislamiento sandbox para limitar las consecuencias de las vulnerabilidades. Actualmente, las posibilidades de utilizar esta tecnología han llegado al límite de sus capacidades y una mayor fragmentación en procesos no es práctica desde el punto de vista del consumo de recursos.

Para mantener la seguridad del código base, Google también aplica "regla de dos“, según el cual cualquier código añadido debe cumplir no más de dos de tres condiciones: trabajar con datos de entrada no validados, utilizar un lenguaje de programación inseguro (C/C++) y ejecutarse con privilegios elevados. Esta regla implica que el código para procesar datos externos debe reducirse a privilegios mínimos (aislado) o escribirse en un lenguaje de programación seguro.

Para mejorar aún más la seguridad del código base, se ha lanzado un proyecto para evitar que aparezcan errores de memoria en el código base. Hay tres enfoques principales: crear bibliotecas C++ con funciones para el funcionamiento seguro de la memoria y ampliar el alcance del recolector de basura, utilizando mecanismos de protección de hardware. MTE (Memory Tagging Extension) y escribir componentes en lenguajes que garanticen un trabajo seguro con la memoria (Java, Kotlin, JavaScript, Rust, Swift).

Se espera que el trabajo se centre en dos áreas:

  • Cambio significativo en el proceso de desarrollo de C++, que no excluye un impacto negativo en el rendimiento (verificaciones de límites adicionales y recolección de basura). En lugar de punteros sin formato, se propone utilizar el tipo MilagroPtr, que le permite reducir los errores de uso después de la liberación explotables a fallas que no representan una amenaza para la seguridad, sin un impacto negativo notable en el rendimiento, el consumo de memoria y la estabilidad.
  • El uso de lenguajes diseñados para realizar comprobaciones de seguridad de la memoria en el momento de la compilación (eliminará el impacto negativo en el rendimiento inherente a dichas comprobaciones durante la ejecución del código, pero generará costos adicionales para organizar la interacción del código en un nuevo lenguaje con el código en C++).

Usar bibliotecas seguras para la memoria es la forma más sencilla, pero también menos eficiente. Reescribir código en Rust se considera la forma más efectiva, pero también muy costosa.

El 70% de los problemas de seguridad en Chromium se deben a errores de memoria

Fuente: opennet.ru

Añadir un comentario