C/C++ Lenguajes de programación inseguros. ¿Existen lenguajes de programación inseguros?

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…

5 Me gusta

Muy interesante este tema.

Ningún lenguaje es inseguro, las vulnerabilidades las crean los programadores.

Excelente aporte, máquina. :ok_hand:t4:

Totalmente de acuerdo… verás como acaba la película XD

¿Será eso que de repente he escuchado como argumento, que este reclamo de que es un lenguaje “inseguro” es en verdad un problema de habilidad de parte de gobierno?

Alguna vez me he topado con ese argumento bajo la frase “that’s an skill issue”.

1 me gusta

Habría que ver el contexto donde se afirma eso.

Yo entiendo que “skill Issue” (tema o problema de habilidad) es responsabilizar a los programadores de falta de conocimientos o de habilidad. Vamos, que cometen errores porque no saben.

Leyendo las notas de prensa de La Casa Blanca y algunos informes que citan, la culpa la trasladan al lenguaje de programación.

Quien comete el error es el programador, cierto es que el lenguaje C, C++ y ensamblador te permite tanta flexibilidad que un error puede ser fatal.

Por otro lado, los fallos los puede cometer tanto un principiante como un veterano. También influye la cantidad de código. En UNIX se fomenta crear programas sencillos que hagan bien una tarea. Eso implica menos código, menos código implica menos probabilidades de fallo y finalmente menos código implica más facilidad para mantenerlo.

2 Me gusta

Hola. Voy a resumir y luego explicar.

Decir que un “lenguaje de programacion” es inseguro, es no saber absolutamente nada del mundo de la computación, o tener otras intenciones detrás de tal afirmación.

Un código fuente, que está escrito en un lenguaje, puede ser inseguro, no el lenguaje, y el lenguaje es escrito por alguien.

Para decir que un lenguaje no es seguro, es que al escribir una instrucción cualquiera, no sabemos lo que hará, es decir, no estamos seguros de que hará dicha instrucción. Sabemos que esta no es la realidad. Contrario a la creencia popular, las computadoras son tontas.

Y esto se entiende con el siguiente chiste, que más que chiste es un principio fundamental, que me enseñaron con 11 años, hace casi ya 30 años cuando aprendía programación y con esto fue casi suficiente para entenderlo todo:

Si le dices a la computadora que se siente, ella se sienta. Pero si no le dices que tome una silla, se sienta en el piso.

5 Me gusta