Los analistas dan la bienvenida al consejo de la NSA para que los desarrolladores adopten lenguajes seguros para la memoria

Los analistas de seguridad recibieron con beneplácito una recomendación de la Agencia de Seguridad Nacional (NSA) de EE. UU. la semana pasada para que los desarrolladores de software consideren la adopción de lenguajes como C#, Go, Java, Ruby, Rust y Swift para reducir las vulnerabilidades relacionadas con la memoria en el código.

La NSA los describió como lenguajes "seguros para la memoria" que administran la memoria automáticamente como parte del lenguaje informático. No dependen del programador para implementar la seguridad de la memoria y, en su lugar, utilizan una combinación de comprobaciones de tiempo de compilación y tiempo de ejecución para protegerse contra errores de memoria, dijo la NSA.

El caso de los lenguajes seguros para la memoria

El aviso un tanto inusual de la NSA del 10 de noviembre señaló lenguajes ampliamente utilizados como C y C++ como confiar demasiado en los programadores no cometer errores relacionados con la memoria, que señaló, sigue siendo la causa principal de las vulnerabilidades de seguridad en el software. Estudios previos—uno por Microsoft en 2019 y otro de Google en 2020 relacionado con su navegador Chrome; por ejemplo, ambos encontraron que el 70% de las vulnerabilidades eran problemas de seguridad de la memoria, dijo la NSA.

“Los lenguajes de uso común, como C y C++, brindan mucha libertad y flexibilidad en la administración de la memoria y dependen en gran medida del programador para realizar las comprobaciones necesarias en las referencias de la memoria”, dijo la NSA. Esto a menudo da como resultado vulnerabilidades explotables vinculadas a errores simples, como errores de desbordamiento de búfer, problemas de asignación de memoria y condiciones de carrera.

C#, Go, Java, Ruby, Rust, Swift y otros lenguajes seguros para la memoria no eliminan por completo el riesgo de estos problemas, dijo la NSA en su aviso. La mayoría de ellos, por ejemplo, incluyen al menos algunas clases o funciones que no son seguras para la memoria y permiten al programador realizar una función de administración de memoria potencialmente insegura. Los lenguajes seguros para la memoria a veces también pueden incluir bibliotecas escritas en lenguajes que contienen funciones de memoria potencialmente inseguras.

Pero incluso con estas advertencias, los lenguajes seguros para la memoria puede ayudar a reducir las vulnerabilidades en el software como resultado de una mala y descuidada gestión de la memoria, dijo la NSA.

Tim Mackey, principal estratega de seguridad en Synopsys Cybersecurity Research Center, agradece la recomendación de la NSA. El uso de lenguajes seguros para la memoria debería, de hecho, ser el predeterminado para la mayoría de las aplicaciones, dice. “Para fines prácticos, confiar en los desarrolladores para que se concentren en los problemas de administración de la memoria en lugar de programar nuevas funciones interesantes representa un impuesto a la innovación”, dice. Con los lenguajes de programación seguros para la memoria y los marcos asociados, son los autores del lenguaje los que aseguran una gestión adecuada de la memoria y no los desarrolladores de aplicaciones, dice Mackey.

El cambio puede ser un desafío

Cambiar un entorno de desarrollo de software maduro de un idioma a otro puede ser difícil, reconoció la NSA. Los programadores necesitarán aprender el nuevo lenguaje, y es probable que haya errores de novatos y problemas de eficiencia durante el proceso. El grado de seguridad de la memoria que está disponible también puede variar significativamente según el idioma. Algunos pueden ofrecer solo una seguridad de memoria mínima, mientras que otros ofrecen protecciones considerables en torno al acceso, la asignación y la administración de la memoria.

Además, las organizaciones necesitarán considerar qué compensación están dispuestas a hacer entre seguridad y rendimiento. “La seguridad de la memoria puede ser costosa en rendimiento y flexibilidad”, advirtió la NSA. "Para los lenguajes con un nivel extremo de protección inherente, es posible que se necesite un trabajo considerable para simplemente compilar el programa debido a las comprobaciones y protecciones".

Hay innumerables variables en juego cuando se intenta portar una aplicación de un idioma a otro, dice Mike Parkin, ingeniero técnico senior de Vulcan Cyber. “En el mejor de los casos, el cambio es simple y una organización puede lograrlo relativamente sin problemas”, dice Parkin. “En otros, la aplicación se basa en características que son triviales en el idioma original pero que requieren un desarrollo extenso y costoso para recrearlas en el nuevo”.

El uso de lenguajes seguros para la memoria tampoco reemplaza la necesidad de realizar pruebas de software adecuadas, advierte Mackey. El hecho de que un lenguaje de programación sea seguro para la memoria no significa que el lenguaje o las aplicaciones desarrolladas en él estén libres de errores.

Pasar de un lenguaje de programación a otro es una propuesta arriesgada a menos que tenga personal que ya entienda tanto el lenguaje antiguo como el nuevo, dice Mackey. “Tal migración se realiza mejor cuando la aplicación está pasando por una actualización de versión principal; de lo contrario, existe la posibilidad de que se introduzcan errores involuntarios como parte del esfuerzo de migración”, señala.

Mackey sugiere que las organizaciones consideren el uso de microservicios cuando se trata de cambiar de idioma. “Con una arquitectura de microservicios, la aplicación se descompone en un conjunto de servicios en contenedores”, dice Mackey. “Desde la perspectiva de un lenguaje de programación, no hay nada que requiera inherentemente que cada microservicio se programe en el mismo lenguaje de programación que otros servicios dentro de la misma aplicación”.

Haciendo el movimiento

Datos recientes de Statista muestran que muchos desarrolladores ya están usando idiomas que se consideran seguros para la memoria. Casi dos tercios (65.6 %), por ejemplo, usa JavaScript, casi la mitad (48.06 %) usa Python, un tercio usa Java y casi el 28 % usa C#. Al mismo tiempo, una proporción sustancial todavía utiliza lenguajes no seguros como C++ (22.5 %) y C (19.25 %).

“Creo que muchas organizaciones ya se han alejado de C/C++ no solo por el problema de la seguridad de la memoria, sino también por la facilidad general de desarrollo y mantenimiento”, dice Johannes Ullrich, decano de investigación del SANS Technology Institute. “Pero aún habrá bases de código heredadas que deberán mantenerse durante muchos años”.

El aviso de la NSA ofreció poca información sobre lo que podría haber motivado su recomendación en este momento. Pero John Bambenek, principal cazador de amenazas de Netenrich, aconseja que las organizaciones no lo ignoren. “Las vulnerabilidades de memoria y los ataques se han generalizado desde la década de 1990, por lo que, en general, este es un buen consejo”, dice. “Dicho esto, como esto proviene de la NSA, creo que este consejo debería ser más urgente y está siendo impulsado por el conocimiento que ellos tienen y nosotros no”.