Más de la mitad de los proyectos de código abierto contienen código escrito en un lenguaje que no es seguro para la memoria, un Informe de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos Se ha descubierto que no es seguro para la memoria. Esto significa que el código permite operaciones que pueden dañar la memoria, lo que genera vulnerabilidades como desbordamientos de búfer, uso después de liberación y fugas de memoria.
Los resultados del informe, publicado conjuntamente con el FBI, el Centro Australiano de Seguridad Cibernética de la Dirección de Señales de Australia y el Centro Canadiense de Seguridad Cibernética, se basan en el análisis de 172 proyectos críticos definidos por el grupo de trabajo de Protección de Proyectos Críticos de OpenSSF.
Del total de líneas de código de estos proyectos, el 55 % se escribió en un lenguaje que no es seguro para la memoria, y los proyectos más grandes contienen más. Las líneas que no son seguras para la memoria representan más de una cuarta parte de los 10 proyectos más grandes del conjunto de datos, mientras que la proporción media entre ellos es del 62,5 %. Cuatro de ellos están compuestos por más del 94 % de código que no es seguro para la memoria.
¿Qué son los lenguajes que no son seguros para la memoria?
Los lenguajes que no son seguros para la memoria, como C y C++, requieren que los desarrolladores implementen manualmente prácticas rigurosas de administración de memoria, que incluyen una cuidadosa asignación y desasignación de memoria. Naturalmente, se cometerán errores que darán lugar a vulnerabilidades que pueden permitir a los adversarios tomar el control del software, los sistemas y los datos.
Por otro lado, los lenguajes seguros para la memoria, como Python, Java, C# y Rust, manejan automáticamente la gestión de la memoria a través de características integradas y transfieren la responsabilidad al intérprete o compilador.
VER: Los 10 mejores cursos de Python que vale la pena realizar en 2024
Los autores del informe escribieron: “Las vulnerabilidades de seguridad de la memoria se encuentran entre las clases más frecuentes de vulnerabilidad de software y generan costos sustanciales tanto para los fabricantes de software como para los consumidores relacionados con la aplicación de parches, la respuesta a incidentes y otros esfuerzos”.
También analizaron las dependencias de software en tres proyectos escritos en lenguajes seguros para la memoria y descubrieron que cada uno de ellos dependía de otros componentes escritos en lenguajes no seguros para la memoria.
“Por lo tanto, determinamos que la mayoría de los proyectos críticos de código abierto analizados, incluso aquellos escritos en lenguajes seguros para la memoria, potencialmente contienen vulnerabilidades de seguridad de memoria”, escribieron los autores.
Chris Hughes, asesor jefe de seguridad de la empresa de seguridad de código abierto Endor Labs y miembro de innovación cibernética de CISA, dijo a TechRepublic: “Los hallazgos sin duda plantean un riesgo tanto para las organizaciones comerciales como para las agencias gubernamentales debido a la explotación predominante de esta clase de vulnerabilidades cuando analizamos la explotación anual en todas las clases de vulnerabilidades. A menudo se encuentran entre las La clase de vulnerabilidades más comúnmente explotada año tras año.”
¿Por qué es tan frecuente el código que no es seguro para la memoria?
El código que no es seguro para la memoria es muy común porque brinda a los desarrolladores la capacidad de manipular directamente el hardware y la memoria. Esto es útil en casos en los que las limitaciones de rendimiento y recursos son factores críticos, como en los núcleos y controladores de los sistemas operativos, la criptografía y las redes para aplicaciones integradas. Los autores del informe observaron esto y esperan que continúe.
Los desarrolladores pueden usar lenguajes que no son seguros para la memoria directamente porque no son conscientes de los riesgos o no les preocupan. También pueden desactivar intencionalmente las funciones seguras para la memoria de un lenguaje seguro para la memoria.
Sin embargo, quienes conocen los riesgos y no desean incorporar código que no sea seguro para la memoria pueden hacerlo de manera no intencionada a través de una dependencia de un proyecto externo. Realizar un análisis de dependencias exhaustivo es un desafío por varias razones, lo que hace que sea fácil que se cuelen dependencias que no sean seguras para la memoria.
En primer lugar, los lenguajes suelen tener múltiples mecanismos para especificar o crear dependencias, lo que complica el proceso de identificación. Además, hacerlo es costoso en términos computacionales, ya que se requieren algoritmos sofisticados para rastrear todas las interacciones potenciales y los efectos secundarios.
“En algún lugar debajo de cada pila de lenguaje de programación y gráfico de dependencia, se escribe y ejecuta código que no es seguro para la memoria”, escribieron los autores.
VER: Un estudio de Aqua Security revela un aumento del 1400 % en los ataques a la memoria
Hughes le dijo a TechRepublic: “A menudo, estos lenguajes (no seguros para la memoria) han sido ampliamente adoptados y utilizados durante años antes de que se produjeran muchas de las actividades recientes para intentar fomentar la transición a lenguajes seguros para la memoria. Además, existe la necesidad de que la comunidad de desarrollo más amplia realice la transición a lenguajes seguros para la memoria más modernos.
“Sería difícil cambiar muchos de estos proyectos a lenguajes seguros para la memoria porque se requerirían recursos y esfuerzos de los encargados del mantenimiento para refactorizarlos o reescribirlos a lenguajes seguros para la memoria. Es posible que los encargados del mantenimiento no tengan experiencia en el lenguaje seguro para la memoria e incluso si la tuvieran, es posible que no tengan incentivos para hacerlo, dado que en su mayoría son voluntarios no remunerados que no reciben compensación por los proyectos que han creado y mantenido”.
Agregó que las organizaciones deberían ofrecer incentivos monetarios y otros recursos para alentar a los desarrolladores de código abierto a realizar la transición de su código, pero también deben monitorear cualquier esfuerzo para garantizar que se implementen prácticas de codificación seguras.
Recomendaciones para reducir los riesgos de código que no es seguro para la memoria
El informe se refiere a El caso de la CISA en favor de hojas de ruta para la seguridad de la memoria documento y del Consejo Asesor Técnico Informe sobre la seguridad de la memoria para obtener recomendaciones sobre cómo reducir la prevalencia de lenguajes que no son seguros para la memoria. Estas recomendaciones incluyen:
- Realizar la transición de los proyectos existentes a lenguajes seguros para la memoria, ya que los avances recientes significan que ahora tienen un rendimiento paralelo al de los lenguajes no seguros para la memoria.
- Escriba nuevos proyectos en lenguajes que utilicen memoria segura.
- Cree hojas de ruta de seguridad de memoria que incluyan planes claros para integrar la programación de seguridad de memoria en los sistemas y abordar la seguridad de la memoria en dependencias externas.
- Gestione las dependencias externas garantizando que las bibliotecas y los componentes de terceros también sean seguros para la memoria o tengan mitigaciones implementadas.
- Capacitar a los desarrolladores en lenguajes que utilizan memoria segura.
- Priorizar la seguridad en el diseño de software desde el comienzo del ciclo de vida del software, por ejemplo, adhiriéndose a Principios de seguridad por diseño.
Esfuerzos de los funcionarios para reducir la prevalencia de códigos que no son seguros para la memoria
En los últimos años, funcionarios federales e investigadores de Estados Unidos han estado trabajando para reducir la cantidad de software que no es seguro para la memoria en circulación.
Un Informe de octubre de 2022 Consumer Reports señaló que “aproximadamente entre el 60 y el 70 por ciento de las vulnerabilidades del navegador y del kernel (y los errores de seguridad encontrados en las bases de código C/C++) se deben a la falta de seguridad de la memoria”. Luego, la Agencia de Seguridad Nacional publicó una guía para Cómo los desarrolladores de software podrían protegerse contra problemas de seguridad de la memoria.
En 2023, la directora de CISA, Jen Easterly, pidió a las universidades que Educar a los estudiantes sobre la seguridad de la memoria. y prácticas de codificación seguras. Estrategia Nacional de Ciberseguridad 2023 y se publicó su plan de implementación, en el que se discutió Invertir en lenguajes seguros para la memoria y Colaborando con la comunidad de código abierto para defenderlos aún más. Ese diciembre, CISA publicó El caso de las hojas de ruta seguras para la memoria y el Consejo Asesor Técnico Informe sobre la seguridad de la memoria.
En febrero de este año, el La Casa Blanca publicó un informe que promueve el uso de lenguajes seguros para la memoria y el desarrollo de estándares de seguridad de software, que fue respaldado por importantes empresas de tecnología, incluidas SAP y Hewlett Packard Enterprise.
Los esfuerzos del gobierno de los EE. UU. están siendo apoyados por una serie de grupos de terceros que comparten su objetivo de reducir la prevalencia de código que no es seguro para la memoria. El grupo de trabajo de mejores prácticas de OpenSSF tiene un grupo de trabajo dedicado a este tema. Interés especial en seguridad de la memoria subgrupo, mientras que el Grupo de Investigación de Seguridad de Internet Proyecto Prossimo quiere “mover la infraestructura de software sensible a la seguridad de Internet a un código seguro para la memoria”. Google ha desarrollado el Fuzz de OSS servicio que prueba continuamente software de código abierto para detectar vulnerabilidades de seguridad de memoria y otros errores utilizando técnicas de fuzzing automatizadas.
