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, según un informe de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos. Memoria insegura significa que el código permite operaciones que pueden dañar la memoria, lo que genera vulnerabilidades como desbordamientos del búfer, uso después de la liberación y pérdidas 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 Seguridad de Proyectos Críticos de OpenSSF.
Del total de líneas de código para estos proyectos, el 55% se escribieron en un lenguaje que no es seguro para la memoria, y los proyectos más grandes contenían más. Las líneas con memoria insegura 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 se componen de más del 94% de código no 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, incluida la asignación y desasignación cuidadosa de la memoria. Naturalmente, se cometerán errores que darán como resultado 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 administración de la memoria a través de funciones 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 del 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, contienen potencialmente vulnerabilidades de seguridad de la 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 ciertamente representan un riesgo tanto para las organizaciones comerciales como para las agencias gubernamentales debido a la explotación predominante de esta clase de vulnerabilidades cuando observe la explotación anual en todas las clases de vulnerabilidades. A menudo se encuentran entre la clase de vulnerabilidades más comúnmente explotadas 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 prevalece porque brinda a los desarrolladores la capacidad de manipular directamente el hardware y la memoria. Esto es útil en casos donde las limitaciones de rendimiento y recursos son factores críticos, como en los núcleos y controladores del sistema operativo, la criptografía y las redes para aplicaciones integradas. Los autores del informe observaron esto y esperan que continúe.
Los desarrolladores pueden utilizar lenguajes no seguros para la memoria directamente porque desconocen los riesgos o no les molestan. También pueden desactivar intencionalmente las funciones de seguridad de memoria de un lenguaje seguro de memoria.
Sin embargo, aquellos conscientes de los riesgos y que no deseen incorporar código que no sea seguro para la memoria podrían hacerlo sin querer a través de una dependencia de un proyecto externo. Realizar un análisis de dependencia integral es un desafío por varias razones, lo que facilita que las dependencias que no son seguras para la memoria pasen desapercibidas.
Por un lado, 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 desde el punto de vista computacional, ya que se requieren algoritmos sofisticados para rastrear todas las posibles interacciones y 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 encuentra un aumento del 1400 % en los ataques a la memoria
Hughes dijo a TechRepublic: “A menudo, estos lenguajes (no seguros para la memoria) han sido ampliamente adoptados y utilizados durante años antes de gran parte de la actividad reciente para intentar fomentar la transición a lenguajes seguros para la memoria. Además, existe la necesidad de que la comunidad de desarrollo en general haga la transición a lenguajes más modernos y seguros para la memoria.
“Sería difícil cambiar muchos de estos proyectos a lenguajes seguros para la memoria porque requeriría recursos y esfuerzos por parte de los mantenedores para refactorizar/reescribir en lenguajes seguros para la memoria. Es posible que los mantenedores no tengan experiencia en el lenguaje seguro de la memoria e incluso si la tuvieran, es posible que no estén incentivados a hacerlo, dado que son en gran medida voluntarios no remunerados que no reciben compensación por los proyectos que han creado y mantenido”.
Añadió 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 segura.
Recomendaciones para reducir los riesgos de código no seguro para la memoria
El informe hace referencia al documento The Case for Memory Safe Roadmaps de CISA y al informe del Consejo Asesor Técnico sobre 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:
- Haga la transición de los proyectos existentes a lenguajes seguros para la memoria, ya que los avances recientes significan que ahora son paralelos al rendimiento de los lenguajes no seguros para la memoria.
- Escriba nuevos proyectos en lenguajes seguros para la memoria.
- Cree hojas de ruta seguras para la memoria que incluyan planes claros para integrar la programación segura para la memoria en los sistemas y abordar la seguridad de la memoria en dependencias externas.
- Administre las dependencias externas asegurándose de que las bibliotecas y componentes de terceros también sean seguros para la memoria o tengan mitigaciones implementadas.
- Capacite a los desarrolladores en lenguajes seguros para la memoria.
- Priorizar la seguridad en el diseño de software desde el comienzo del ciclo de vida del software, por ejemplo, adhiriéndose a los principios de Secure by Design.
Esfuerzos de los funcionarios para reducir la prevalencia de códigos no seguros para la memoria
Los funcionarios federales y los investigadores de Estados Unidos han estado trabajando para reducir la cantidad de software no seguro para la memoria en circulación en los últimos años.
Un informe de octubre de 2022 de 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ódigos C/C++, se deben a la inseguridad de la memoria”. Luego, la Agencia de Seguridad Nacional publicó una guía sobre 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 eduquen a los estudiantes sobre la seguridad de la memoria y las prácticas de codificación segura. Luego se publicó la Estrategia Nacional de Ciberseguridad 2023 y su plan de implementación, en el que se analizaba la inversión en lenguajes seguros para la memoria y la colaboración con la comunidad de código abierto para defenderlos aún más. Ese diciembre, CISA publicó The Case for Memory Safe Roadmaps y el informe del Consejo Asesor Técnico sobre seguridad de la memoria.
En febrero de este año, 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 contó con el respaldo de importantes empresas de tecnología, incluidas SAP y Hewlett Packard Enterprise.
Los esfuerzos del gobierno de EE. UU. cuentan con el apoyo de varios grupos de terceros que comparten su objetivo de reducir la prevalencia de códigos no seguros para la memoria. El Grupo de Trabajo de Mejores Prácticas de OpenSSF tiene un subgrupo de interés especial sobre seguridad de la memoria, mientras que el proyecto Prossimo del Grupo de Investigación de Seguridad de Internet quiere “mover la infraestructura de software sensible a la seguridad de Internet a un código seguro para la memoria”. Google ha desarrollado el servicio OSS-Fuzz que prueba continuamente el software de código abierto en busca de vulnerabilidades de seguridad de la memoria y otros errores utilizando técnicas de fuzzing automatizadas.
