Una actualización sobre la seguridad de la memoria en Chrome


La seguridad es un juego del gato y el ratón. A medida que los atacantes innovan, los navegadores siempre tienen que montar nuevas defensas para mantenerse a la vanguardia, y Chrome ha invertido en una arquitectura multiproceso cada vez más sólida basada en sandboxing y aislamiento del sitio. Combinado con fuzzing, estas siguen siendo nuestras principales líneas de defensa, pero están llegando a sus límites, y ya no podemos confiar únicamente en esta estrategia para derrotar ataques en la naturaleza.

El año pasado, demostramos que más del 70% de nuestros errores de seguridad graves son problemas de seguridad de la memoria. Es decir, errores con punteros en los lenguajes C o C ++ que hacen que la memoria se malinterprete.

¡Esto suena como un problema! Y, ciertamente, la seguridad de la memoria es un tema que la comunidad mundial de ingenieros de software program debe tomar en serio. Sin embargo, también es una oportunidad porque muchos errores tienen el mismo tipo de causas raíz, lo que significa que podemos eliminar una gran proporción de nuestros errores en un solo paso.

Chrome ha estado explorando tres amplias vías para aprovechar esta oportunidad:

  1. Haga que C ++ sea más seguro mediante comprobaciones en tiempo de compilación de que los punteros son correctos.
  2. Haga que C ++ sea más seguro mediante comprobaciones en tiempo de ejecución de que los punteros son correctos.
  3. Investigar el uso de un lenguaje seguro para la memoria para partes de nuestro código foundation.

«Verificaciones en tiempo de compilación» significa que la seguridad está garantizada durante el proceso de compilación de Chrome, incluso antes de que Chrome llegue a su dispositivo. «Tiempo de ejecución» significa que realizamos comprobaciones mientras Chrome se está ejecutando en su dispositivo.

Las comprobaciones en tiempo de ejecución tienen un coste de rendimiento. Verificar la exactitud de un puntero es un costo infinitesimal en memoria y tiempo de CPU. Pero con millones de punteros, se suma. Y dado que el rendimiento de Chrome es importante para miles de millones de usuarios, muchos de los cuales utilizan dispositivos móviles de bajo consumo y sin mucha memoria, un aumento en estas comprobaciones resultaría en una world-wide-web más lenta.

Idealmente, elegiríamos la opción 1: hacer que C ++ sea más seguro, en tiempo de compilación. Desafortunadamente, el lenguaje no está diseñado de esa manera. Puede obtener más información sobre la investigación que hemos realizado en esta área en Problemas de préstamos: las dificultades de un verificador de préstamos de C ++ que también publicamos hoy.

Entonces, nos quedamos principalmente con las opciones 2 y 3: hacer que C ++ sea más seguro (¡pero más lento!) o empiece a usar un idioma diferente. Chrome Stability está experimentando con ambos enfoques.

Verá importantes inversiones en soluciones de seguridad C ++, como MiraclePtr y Modos endurecidos ABSL / STL. En cada caso, esperamos eliminar una fracción sizeable de nuestros errores de seguridad explotables, pero también esperamos alguna penalización en el rendimiento. Por ejemplo, MiraclePtr previene los errores de uso después de la liberación al poner en cuarentena la memoria a la que aún se puede hacer referencia. En muchos dispositivos móviles, la memoria es muy valiosa y es difícil ahorrar algo para una cuarentena. Sin embargo, MiraclePtr tiene la posibilidad de eliminar más del 50% de los errores de uso después de la liberación en el proceso del navegador, una enorme ganar para la seguridad de Chrome, ahora mismo.

En paralelo, exploraremos si podemos usar un lenguaje seguro para la memoria para partes de Chrome en el futuro. El principal contendiente es Oxido, inventado por nuestros amigos de Mozilla. Esto es (en gran medida) seguro en tiempo de compilación es decir, el compilador de Rust detecta errores con punteros antes de que el código llegue a su dispositivo y, por lo tanto, no hay penalización en el rendimiento. Sin embargo, hay preguntas abiertas sobre si podemos hacer que C ++ y Rust funcionen lo suficientemente bien juntos. Incluso si comenzáramos a escribir nuevos componentes grandes en Rust mañana, es poco possible que eliminemos una proporción significativa de vulnerabilidades de seguridad durante muchos años. ¿Y podemos hacer que el límite del lenguaje sea lo suficientemente limpio como para poder escribir partes de componentes existentes en Rust? Aún no lo sabemos. Hemos comenzado a realizar experimentos de Rust limitados y no orientados al usuario en el Árbol de código fuente de cromo, pero aún no lo estamos usando en las versiones de producción de Chrome permanecemos en una fase experimental.

Por eso estamos aplicando ambas estrategias en paralelo. Mire este espacio para obtener actualizaciones sobre nuestras aventuras para hacer que C ++ sea más seguro y los esfuerzos para experimentar con un nuevo lenguaje en Chrome.



Enlace a la noticia primary