Aproximadamente el 70% de todos los errores de seguridad graves en la base del código de Chrome son errores de administración de memoria, según dijeron los ingenieros de Google esta semana.
La mitad de ese 70% son vulnerabilidades user-after-free, un tipo de problema de seguridad que surge de la administración incorrecta de los punteros de memoria (direcciones), dejando las puertas abiertas para que los atacantes puedan atacar los componentes internos de Chrome.
El porcentaje fue calculado después de que los ingenieros de Google analizaran 912 errores de seguridad arreglados en la rama estable de Chrome desde 2015, errores que tenían una calificación de severidad «alta» o «crítica».
El número es idéntico a las estadísticas compartidas por Microsoft. En una conferencia de seguridad en febrero de 2019, los ingenieros de Microsoft dijeron que durante los últimos 12 años, alrededor del 70% de todas las actualizaciones de seguridad para los productos de Microsoft arreglaban las vulnerabilidades provocadas por la gestión de la memoria.
Ambas empresas se enfrentan básicamente al mismo problema: C y C++. Los dos lenguajes de programación predominantes en sus bases de datos de código, son lenguajes «inseguros».
Son lenguajes que llevan con nosotros desde hace décadas, cuando la explotación de la seguridad y los ciberataques no eran un modelo de amenaza relevante y estaban lejos de la mente de la mayoría de los primeros desarrolladores de software.
Como resultado, tanto C como C++ permiten a los programadores tener un control total sobre la forma en que gestionan los punteros de memoria (direcciones) de una aplicación y no vienen con restricciones o advertencias para evitar o alertar a los desarrolladores cuando están cometiendo errores básicos de gestión de memoria.
Estos errores de programación provocan que se introduzcan vulnerabilidades de gestión de memoria en las aplicaciones. Esto incluye vulnerabilidades como user-after-free, desbordamiento de búfer -más conocido con su traducción inglesa, buffer overflow-, condiciones de carrera, doble libre, punteros salvajes y otras.
Estas vulnerabilidades de gestión de memoria son los errores más buscados por los atacantes, ya que pueden concederles la capacidad de introducir código dentro de la memoria de un dispositivo y hacer que lo ejecute la aplicación víctima (navegador, servidor, sistema operativo, etc.).
En un ránking publicado a principios de año, la Corporación MITRE, la organización que gestiona la base de datos de vulnerabilidades del gobierno estadounidense, clasificó el buffer overflow como la vulnerabilidad más peligrosa, con otros dos problemas relacionados con la gestión de la memoria también clasificados entre los 10 primeros (out-of-bounds read en #5 y use-after-free on #7).
A medida que la ingeniería de software ha avanzado en los últimos años, los desarrolladores han ido mejorando en la eliminación de la mayoría de los fallos de seguridad y en la adición de protecciones de seguridad, pero no para las vulnerabilidades de gestión de memoria.
Google dice que desde marzo de 2019, 125 de las 130 vulnerabilidades de Chrome con una clasificación de severidad «crítica» eran problemas relacionados con la corrupción de la memoria, lo que demuestra que, a pesar de los avances en la corrección de otras clases de errores, la gestión de la memoria sigue siendo un problema.
El problema de los errores de administración de memoria ha sido un problema tan grande en Google que los ingenieros de Chrome ahora tienen que seguir «La regla del 2».
De acuerdo con esta regla, cada vez que los ingenieros escriben una nueva característica de Chrome, su código no debe romper más de dos de las siguientes condiciones:
- El código maneja entradas no confiables
- El código funciona sin caja de arena
- El código está escrito en un lenguaje de programación inseguro (C/C++)
Aunque muchas compañías de desarrollo software han intentado en el pasado arreglar los problemas de administración de memoria de C y C++, Mozilla ha sido el que ha hecho un gran avance al patrocinar, promover y adoptar fuertemente el lenguaje de programación Rust en Firefox.
Hoy en día, Rust está considerado como uno de los lenguajes de programación más seguros y un sustituto ideal del C y el C++, principalmente debido a los primeros esfuerzos de Mozilla.
Pero Mozilla no ha sido la única organización que se ha cansado de lidiar con código C y C++ propenso a los errores. Microsoft también está invirtiendo fuertemente en la exploración de alternativas de C y C++. Desde sus primeros proyectos de C comprobado, la compañía está experimentando con Rust, y también está construyendo su propio lenguaje de programación «seguro» similar a Rust (parte del secreto Proyecto Verona).
Hablando en la conferencia virtual de Build esta semana, Microsoft dijo que estos dos esfuerzos han sido exitosos, y la compañía se re-dedicó a adoptar un lenguaje de programación seguro en el futuro.
Google también ha anunciado planes similares esta semana. La compañía dijo que también planea investigar «abordar el problema de la inseguridad al gestionar la memoria» para Chrome, el navegador web más popular de hoy en día, utilizado por casi el 70% de los usuarios de Internet.
Más información:
Informe de The Chromium Projects
https://www.chromium.org/Home/chromium-security/memory-safety
¿Qué se dice en la red?
https://developers.slashdot.org/story/20/05/24/1349204/chromium-project-finds-70-of-its-serious-security-bugs-are-memory-safety-problems
ZDNet
https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/
Es común , aunque solo sea por estilo, enlazar a los sitios de donde se saca la información. Hay párrafos enteros copiados de aquí https://www.muyseguridad.net/2020/05/25/vulnerabilidades-de-chrome-memoria/
Gracias
Hola, Juan:
En primer lugar, muchas gracias por comentar. En este caso, hay partes del artículo que se han traducido y complementado tomando como referencia el post original de Chromium así como otras fuentes de habla inglesa.
Puede llegar a suceder que otro redactor coincida en las mismas fuentes, obteniendo un resultado que pudiera ser similar.
Todas las referencias usadas en este artículo se pueden encontrar en el pie del mismo como es habitual.
Un saludo.
Sí, traducidas hasta las «comas» 😀
O con fecha de publicación del 22 de mayo cuando una de sus «referencias» (ZDnet) publicó un día después, el 23.. No pierdo un segundo más. Nos sobra tráfico, pero no son maneras. Ustedes sabrán
Hola de nuevo,
Sí, parece que hubo un error en la fecha de publicación, ya lo hemos corregido. Pedimos disculpas y muchas gracias por avisar.
Saludos.