lunes, 25 de mayo de 2020

El 70% de las vulnerabilidades en Chrome están relacionadas con la seguridad de la memoria.


Los expertos de Google estimaron que aproximadamente el 70% de los problemas de seguridad en la base de código de Chrome están relacionados con la administración de memoria. Ahora la compañía está tratando de descubrir la mejor manera de resolver este problema.

En total, los ingenieros de Google estudiaron 912 errores (gravedad "alta" o "crítica") que se corrigieron en la rama estable de Chrome desde 2015. Al final resultó que, la mitad del 70% anterior son vulnerabilidades sin uso que surgen debido a la gestión incorrecta de los punteros de memoria, que finalmente abre los componentes internos de Chrome para los ataques.

Curiosamente, las conclusiones de los expertos de Google están de acuerdo con las estadísticas de Microsoft, que el año pasado llegaron a una conclusión similar: en los últimos 12 años, el 70% de los parches para los productos de la compañía se lanzaron por problemas de seguridad de la memoria.

De hecho, ambas compañías sufren lo mismo: el uso de los lenguajes C y C ++, que se consideran "inseguros". El hecho es que estas son herramientas muy antiguas creadas hace décadas, en un momento en que los ataques cibernéticos y la explotación de vulnerabilidades no representaban una amenaza como la actual, y la mayoría de los desarrolladores de software simplemente no pensaban en tales matices.

Entonces, al tratar con C y C ++, los desarrolladores tienen control total sobre la administración de los punteros de memoria en la aplicación. No hay restricciones ni advertencias para advertir a los desarrolladores si cometen errores básicos en problemas de administración de memoria. Como resultado, surgen muchas vulnerabilidades en aplicaciones relacionadas con desbordamientos de búfer, el uso después de liberación, las condiciones de carrera, doble liberación, y así sucesivamente .

Dichas vulnerabilidades son muy populares entre los atacantes, ya que dichos errores pueden usarse para inyectar código en la memoria del dispositivo y luego ejecutar este código en la aplicación de destino (navegador, servidor, sistema operativo, etc.).

Los ingenieros de Google escriben que entre marzo de 2019 y el presente, se han solucionado 130 vulnerabilidades críticas en Chrome. De estos, 125 estaban relacionados de alguna manera con la violación de la integridad de la información en la memoria. Es decir, a pesar de los logros de los desarrolladores en el campo de la corrección de errores de otras clases, la administración de memoria sigue siendo un problema.

Todo esto se ha convertido en un problema tan grande para Google que los ingenieros de Chrome ahora deben seguir la Regla de los dos . De acuerdo con esta regla, cuando los desarrolladores de Chrome escriben una nueva función, su código puede violar no más de dos de las siguientes condiciones:

  • el código procesa entradas no confiables;
  • el código funciona sin una caja de arena;
  • El código está escrito en un lenguaje de programación inseguro (C / C ++).

Hasta hace poco, los ingenieros de Google eran grandes defensores del uso del sandbox en Chrome. Por lo tanto, aislaron docenas de procesos en su propio entorno de software e implementaron  Site Isolation  (coloca los recursos de cada sitio en sus propios procesos aislados en el sandbox). Sin embargo, ahora la compañía se ve obligada a buscar otros enfoques, señalando que el uso de cajas de arena ahora ha alcanzado su máximo con respecto al rendimiento.

En el futuro, Google planea desarrollar bibliotecas C ++ personalizadas con una mejor protección contra errores de memoria. Estas bibliotecas se utilizarán con la base de código de Chrome. Los ingenieros de la compañía también están explorando la posibilidad de utilizar el proyecto  MiraclePtr , cuyo objetivo es convertir las vulnerabilidades sin uso en fallas no relacionadas con la seguridad que tendrán un impacto mínimo en el rendimiento, la estabilidad, la memoria y el tamaño de los archivos binarios.

No olvides Compartir... 
Siguenos en twitter: @disoftin - @fredyavila

No hay comentarios:

Publicar un comentario

Más leídas este mes