Continuando la discusión desde C/C++ Lenguajes de programación inseguros. ¿Existen lenguajes de programación inseguros?:
Veníamos de que La Casa Blanca lidera una serie de acciones para solventar problemas de seguridad informática a gran escala.
Sus asesores y diversas instituciones ponen el foco en las vulnerabilidades relacionadas con la gestión de la memoria. Estas suponen el 70% de las vulnerabilidades. El denominador común es el uso de los lenguajes de programación C y C++. No aclaran si en exclusiva o hay otros lenguajes de programación en ese 70%.
Se crea una clasificación en relación a la seguridad del manejo de memoria:
- Lenguajes seguros (Memory safe)
- Lenguajes no seguros (Non-memory safe)
El el primer grupo aparece como ejemplo Rust. En el segundo solo C y C++.
Hasta ahora no se ha especificado qué mecanismo o característica en el manejo de memoria es el problemático.
El siguiente informe de la NSA nos aclara las incógnitas:
Software Memory Safety
Executive summary
Modern society relies heavily on software-based automation, implicitly trusting developers to write software that operates in the expected way and cannot be compromised for malicious purposes. While developers often perform rigorous testing to prepare the logic in software for surprising conditions, exploitable software vulnerabilities are still frequently based on memory issues. Examples include a memory buffer and leveraging issues with how software allocates and de- allocates memory. Microsoft® revealed at a conference in 2019 that from 2006 to 2018 70 percent of their vulnerabilities were due to memory safety issues.
El segundo párrafo empieza:
Commonly used languages, such as C and C++, provide a lot of freedom and flexibility in memory management while relying heavily on the programmer to perform the needed checks on memory references. Simple mistakes can lead to exploitable memory-based vulnerabilities.
Los lenguajes usados habitualmente, como C y C++, proveen de mucha libertad y flexibilidad en la gestión de la memoria mientras delegan en el programador la comprobación de las referencias a memoria. Un simple error puede provocar una vulnerabilidad de memoria que puede ser explotable.
Es decir, los lenguajes dé programación no seguros con la memoria, son problemáticos porque dan mucha flexibilidad y libertad, y un error puede desencadenar una vulnerabilidad.
¿Hay más lenguajes de programación inseguros?
The path forward
Memory issues in software comprise a large portion of the exploitable vulnerabilities in existence. NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as
C/C++ and assembly, to a memory safe language when possible. Some examples of memory safe languages are Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada.
Vemos que se incluye le lenguaje ensamblador dentro de la categoría de no seguros. Y el resto totalmente seguros. ¿ O no tan seguros?
Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks.
Incluso los lenguajes seguros deben hacer determinados accesos a memoria que pueden ser inseguros. La seguridad que aportan estos lenguajes se logra a costa de perder flexibilidad y libertad al programar. Y aun así no aporta la certeza de su seguridad.
Conclusión
Los proyectos con lenguajes de programación inseguros se verán perjudicados. Será cada vez más difícil que accedan a financiación y tendrán problemas de apoyo o que puedan competir en proyectos financiados por instituciones públicas.
Si nos fijamos en los tres lenguajes dé programación no seguros, no hay detrás de ellos grandes compañías ni fundaciones que puedan defenderlos ante iniciativas como esta. En los informes de La Casa Blanca se menciona que hubo reuniones, entre otros, con empresas , fundaciones e instituciones académicas. Detrás de los lenguajes seguros si hay actores con peso.
Veremos lo que el futuro deparará a los lenguajes de programación inseguros.
Y para terminar. Aunque se ha barajado soluciones hardware solo se han considerado como complementarias. Y eso que hemos tenido el incidente relacionado con Spectre y Meltdown que afectó a las arquitecturas Intel x86, IBM Power y algunos ARM. Implicó la desactivación de características hardware que repercutió en la reducción del rendimiento.
Me extraña que no se haya debatido sobre la arquitectura Harvard, donde datos y código ejecutable se almacenan en memorias separadas. Esta es la solución más efectiva contra ese 70% de vulnerabilidades.