El Portal de las Tecnologías para la Innovación

Lenguajes de programación seguros: el desafío de la adopción

Estados Unidos hace un nuevo llamado a la adopción de lenguajes de programación seguros… con el posible refuerzo de los métodos formales y la seguridad del hardware.

¿Qué tienen en común el gusano Morris (1988) y la grieta Heartbleed (2014)? Como mínimo, el de haber guardado en la memoria problemas de seguridad.

La Casa Blanca se refiere a esto en una nota técnica relativa a la reducción de la superficie de ataque en el ciberespacio. Ella detalla dos enfoques. Por un lado, el desarrollo de indicadores “empíricos” para medir la seguridad del software. Por otro, la adopción de los llamados lenguajes de programación seguros, es decir, con gestión automática de la memoria.

Sobre este último punto, Washington retoma algunas de las estadísticas que ya había presentado , entre otros, la NSA . Entre ellas, el hecho de que en lenguajes inseguros, hasta el 70% de las vulnerabilidades a las que se les asigna un CVE están relacionadas con problemas de memoria. De hecho , el equipo del proyecto Chromium está comunicando datos en esta dirección. Microsoft lanzó otros similares hace unos años.

Vulnerabilidades de la memoria de Chrome
Vulnerabilidades de la memoria de Microsoft

Además de Morris y Heartbleed, la Casa Blanca menciona el gusano SQL Slammer (2003) y el exploit BLASTPASS (2023). Recuerda la existencia de dos categorías principales de vulnerabilidades de la memoria: espacial (acceso fuera de los límites establecidos) y temporal (explotación de un puntero después de su liberación, acceso inesperadamente intercalado, etc.).

Métodos formales y seguridad basada en hardware.

Ciertos entornos, empezando por los integrados, plantean limitaciones al uso de lenguajes seguros. La nota técnica se centra en un sector en particular: el espacio. Hay tres requisitos: ejecución de bajo nivel, determinismo y ausencia de recolección de basura (o al menos la posibilidad de anularla).

C y C++ son actualmente los lenguajes más utilizados que cumplen estos tres requisitos. Ninguno de los dos entra en la categoría de lenguajes seguros. A diferencia de Rust, que aún no ha sido probado en el ámbito espacial (falta de herramientas, aculturación de los ingenieros y “casos de uso de campo”).

A la espera de esta adopción, la Casa Blanca propone dos técnicas complementarias. En este caso, implemente la seguridad a nivel de hardware y utilice métodos formales.

Sobre el primer punto, da el ejemplo de la arquitectura CHERI (Capability Hardware Enhanced RISC Instrucciones) y la tecnología MTE (extensión de etiquetado de memoria). En cuanto al segundo, cita el análisis estático avanzado, la verificación de modelos y las pruebas basadas en afirmaciones. Métodos que se pueden incorporar a herramientas de desarrollo, a nivel de compilador. Fuente NetMedia Francia(BC), traducido al español

Artículos relacionados

Scroll al inicio