Conocemos protocolos inseguros (p.e. Ftp), aplicaciones con errores de programación que pueden provocar fallos de seguridad. Programas seguros que se vuelven inseguros por un fallo de configuración.
Pero, ¿usar un lenguaje de programación puede crear programas intrínsecamente inseguros?
Esa parece ser la afirmación que se está difundiendo, entre otros, por La Casa Blanca.
La nota de prensa relata La Casa Blanca pide a la comunidad científica que resuelva el problema de cómo establecer un sistema para medir la calidad del software en lo relativo seguridad.
Y a los fabricantes de tecnología que adopten lenguajes de programación memory safe.
Programas seguros para la memoria. ¿Qué significa eso? ¿Y cuáles son los lenguajes seguros y cuales no?
La nota de prensa incluye una referencia al informe que sustentan las medidas que proponen:
En el prólogo nos aclara lo siguiente:
First, in order to reduce memory safety vulnerabilities at scale,
creators of software and hardware can better secure the building blocks of cyberspace. This report focuses on the programming language as a primary building block, and explores hardware architecture and formal methods as complementary approaches to achieve similar outcomes.
“Para reducir las vulnerabilidades a gran escala, los creadores de software y hardware pueden mejorar los bloques fundamentales del ciberespacio. Este informe se centra en los lenguajes de programación como bloque primordial y explora la arquitectura hardware y los métodos formales como complementarios…”
El objetivo es reducir la repercusión a gran escala de las vulnerabilidades relacionadas con la gestión de la memoria. Intersante que se mencione la modificación del hardware.
¿Como van a llevar a cabo estos objetivos?
PART I: INTRODUCTION
…
The Strategy calls for two fundamental shifts in how the United States allocates roles, responsibilities, and resources. First, the Strategy calls for rebalancing the responsibility to defend cyberspace to those most capable and best positioned to reduce risks for all. Second, it notes the need to realign incentives to favor the long-term investments required to make cyberspace more resilient and defensible in the years to come.
…
“Reasignado las responsabilidades a aquellos más capaces y mejor posicionados.” ¿Empresas?
Y “realinear incentivos para investigación a largo plazo”, ¿poner dinero?
Ahora viene qué pasa con los lenguajes de programación:
PART II: SECURING THE BUILDING BLOCKS OF CYBERSPACE
…
Memory safety vulnerabilities are a class of vulnerability affecting how memory can be accessed, written, allocated, or deallocated in unintended ways.Experts have identified a few programming
languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++.Choosing to use memory safe programming languages
at the outset, as recommended by the Cybersecurity and Infrastructure Security Agency’s (CISA) Open-Source Software Security Roadmap is one example of developing software in a secure-by- design manner.
“Las vulnerabilidades de seguridad que afectan a la memoria son una clase de vulnerabilidades que afectan a cómo la memoria puede ser accedida, escrita, asignada o liberada de forma no intencionada. Los expertos han identificado unos lenguajes de programación que carecen de rasgos asociados con la seguridad de la memoria y también tienen una alta proliferación en sistemas críticos, como C y C++”.
En resumen: gran cantidad de sistemas que corren software programado con esos lenguajes y “carecer de rasgos asociados con la seguridad de la memoria”. Exactamente ¿ qué es “carecer de rasgos asociados con la seguridad de la memoria”?
La solución:
Memory Safe Programming Languages
…
Cybersecurity solutions should be informed by engineering best practices, and technology manufacturers building software can tackle this issue by consistently using secure building blocks;
specifically, adopting memory safe programming languages.
Todo pasa por seguir unas buenas prácticas y adoptar lenguajes de programación que gestionen la memoria de forma segura.
¿Cuáles son? Ya veremos. Ahora viene un detalle crucial:
Memory Safe Hardware
…
First, the language must allow the code to be close to the kernel so that it can tightly interact with both software and hardware; second, the language must support determinism so the timing of the outputs are consistent; and third, the language must not have – or be able to override – the “garbage collector,” a function that
automatically reclaims memory allocated by the computer program that is no longer in use. These requirements help ensure the reliable and predictable outcomes necessary for space systems.
According to experts, both memory safe and memory unsafe programming languages meet these requirements. At this time, the most widely used languages that meet all three properties are C and C++, which are not memory safe programming languages. Rust, one example of a memory safe programming language, has the three requisite properties above, but has not yet been proven in space systems.
Esta sección empieza con el accidente del Apolo 13 y las enseñanzas que se extrajeron: en el diseño debe formar parte de manera implícita la seguridad. A lo que se añade ahora el software y las consideraciones de la cita de arriba:
“Primero, el lenguaje debe permitir que el código esté cerca del kernel para que pueda interactuar estrechamente tanto con el software como con el hardware, en segundo lugar, el lenguaje debe admitir el determinismo para que el tiempo de las salidas sea consistente; y en tercer lugar, el lenguaje no debe tener, o ser capaz de anular, el “recolector de basura”, una función que recupera automáticamente la memoria asignada por el programa informático que ya no está en uso.”
En último párrafo se afirma que tanto los lenguajes seguros gestionando la memoria, como los lenguajes no seguros cumplen con esos tres requisitos. Aparece Rust como lenguaje seguro y se vuelven a mencionar a C y C++ como no seguros. Pero seguimos sin saber qué criterios hacen que un lenguaje sea seguro o no.
Esta sección termina mencionando que mejoras en la arquitectura RISC podrían limitar el acceso a la memoria y mitigar las vulnerabilidades. Una propuesta es Capability Hardware Enhanced RISC Instructions (CHERI).
¿Qué criterio marca la diferencia entre los lenguajes seguros y los no seguros?
Lo dejamos por hoy…
