Más de la mitad de los proyectos de código abierto contienen código escrito en un lenguaje no seguro para la memoria, según un informe de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos. El término «no seguro para la memoria» significa que el código permite operaciones que pueden corromper la memoria, lo que genera vulnerabilidades como desbordamientos de búfer, uso después de la liberación y fugas de memoria. Los resultados del informe, publicados 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 no seguro para la memoria, y los proyectos más grandes contienen más. Las líneas no 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 no seguro para la memoria. ¿Qué son los lenguajes no 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, y estos resultan en 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 características integradas y transfieren la responsabilidad al intérprete o compilador. VER: Los 10 mejores cursos de Python que vale la pena tomar 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 en CISA, dijo a TechRepublic: “Los hallazgos ciertamente 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 clases de vulnerabilidades más comúnmente explotadas año tras año”. ¿Por qué es tan frecuente el código inseguro para la memoria? El código inseguro para la memoria es frecuente 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 del sistema operativo, la criptografía y la red para aplicaciones integradas. Los autores del informe observaron esto y esperan que continúe. Cobertura de seguridad de lectura obligada Los desarrolladores pueden usar lenguajes inseguros para la memoria directamente porque desconocen o no les preocupan los riesgos. También pueden desactivar intencionalmente las características de seguridad de memoria de un lenguaje seguro para la memoria. Sin embargo, aquellos conscientes de los riesgos y que no desean incorporar código inseguro para la memoria pueden hacerlo involuntariamente a través de una dependencia en un proyecto externo. Realizar un análisis de dependencia integral es un desafío por varias razones, lo que hace que sea fácil que las dependencias inseguras para la memoria se escapen. Por un lado, los lenguajes a menudo tienen múltiples mecanismos para especificar o crear dependencias, lo que complica el proceso de identificación. Además, hacerlo es computacionalmente costoso, ya que se requieren algoritmos sofisticados para rastrear todas las interacciones potenciales 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 inseguro para la memoria», escribieron los autores. VER: Estudio de Aqua Security encuentra un aumento del 1,400% en ataques a la memoria Hughes le dijo a TechRepublic: «A menudo, estos lenguajes (inseguros para la memoria) han sido ampliamente adoptados y utilizados durante años antes de gran parte de la actividad reciente para tratar de alentar 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 requeriría recursos y esfuerzos de los mantenedores, para refactorizar/reescribir a lenguajes seguros para la memoria. Los mantenedores pueden no tener experiencia en el lenguaje seguro para la memoria e incluso si la tienen, es posible que no estén incentivados a hacerlo, dado que son en gran parte voluntarios no remunerados que no reciben compensación por los proyectos que han creado y mantenido”. Agregó que las organizaciones deben 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 inseguro para la memoria El informe hace referencia al documento The Case for Memory Safe Roadmaps de CISA y al informe del Technical Advisory Council sobre seguridad de la memoria para obtener recomendaciones sobre cómo reducir la prevalencia de lenguajes inseguros para la memoria. Estas recomendaciones incluyen: Transición de proyectos existentes a lenguajes seguros para la memoria, ya que los avances recientes significan que ahora son paralelos al rendimiento de los lenguajes inseguros para la memoria. Escribir nuevos proyectos en lenguajes seguros para la memoria. Crear 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. Gestionar las dependencias externas asegurándose de 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 seguros para la memoria. Priorizar la seguridad en el diseño de software desde el comienzo del ciclo de vida del software, por ejemplo, adhiriendo a los principios de Secure by Design. Esfuerzos de los funcionarios para reducir la prevalencia de código inseguro para la memoria Los funcionarios federales e investigadores en los EE. UU. han estado trabajando para reducir la cantidad de software inseguro para la memoria en circulación en los últimos años. Un informe de octubre de 2022 de Consumer Reports señaló que «aproximadamente del 60 al 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 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 los problemas de seguridad de la memoria. En 2023, la directora de CISA, Jen Easterly, pidió a las universidades que educaran 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, que discutía la inversión en lenguajes seguros para la memoria y la colaboración con la comunidad de código abierto para promoverlos 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 promovía 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 EE. UU. están siendo apoyados por una serie de grupos de terceros que comparten su objetivo de reducir la prevalencia de código inseguro para la memoria. El Grupo de Trabajo de Mejores Prácticas de OpenSSF tiene un subgrupo de Interés Especial dedicado a la 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 memoria y otros errores utilizando técnicas de fuzzing automatizadas.
