Proteger los sistemas tecnológicos críticos de posibles amenazas es una preocupación cada vez mayor para los gobiernos. Y un ejemplo de ello es el reciente llamamiento (PDF) dirigido a la industria del desarrollo de software y realizado por la Casa Blanca a través de la Oficina de su Director Nacional de Ciberseguridad (ONCD) para que adopten lenguajes "seguros para la memoria" lo que pasa por abandonar los lenguajes de programación interpretados como 'inseguros' en esta área, un listado que incluye a los dos principales lenguajes de desarrollo de sistemas operativos: C y C++.

• En su lugar, el gobierno estadounidense pide apostar por Rust, C#, JavaScript...
• No es la primera vez que se pone sobre la mesa este cambio (que difícilmente presenciaremos a corto/medio plazo)

Lenguajes seguros para la memoria

La NSA explica que su recomendación se basa en que los lenguajes seguros para la memoria utilizan una combinación de comprobaciones en tiempo de compilación y de ejecución para bloquear automáticamente las vulnerabilidades causadas por los errores de los programadores. "No todos los errores, pero ayuda", dice el informe.

La misma NSA ofrece ejemplos de lenguajes de memoria segura: C#, Go, Java, Ruby, Rust y Swift. Algunos lenguajes requieren que cualquier cosa insegura para la memoria sea explícitamente anotada como tal para que el programador lo sepa. Los lenguajes al estilo de Rust o Ruby también pueden usar bibliotecas escritas en lenguajes no seguros para la memoria.

Gracias por sus servicios, C/C++, pero...

Los lenguajes C y C++, a pesar de su popularidad y extenso uso en el desarrollo de software (incluyendo sistemas operativos) a lo largo de las últimas décadas, han sido señalados por presentar riesgos de seguridad, especialmente a la hora de usarlos sistemas críticos.

Mientras que lenguajes como Java cuentan con controles de detección de errores en tiempo de ejecución, que los convierten en ejemplos de lenguajes "seguros para la memoria", C o C++ permiten una manipulación directa y sin restricciones de las direcciones de memoria, lo que puede conducir a vulnerabilidades como desbordamientos de búfer.

La ONCD, en su reporte, no se limita a señalar los riesgos asociados con C y C++, sino que también propone alternativas. Lenguajes como Rust, Go, C#, Java, Swift, JavaScript y Ruby son mencionados como opciones seguras en cuanto a la memoria.

Es importante incidir en que, sin embargo, la ONCD no ha establecido una lista de lenguajes de programación 'permitidos' o 'prohibidos', sino que (por ahora) sólo busca fomentar una mayor conciencia sobre los riesgos asociados con ciertos lenguajes.

Un cambio difícil... ¿e innecesario?

Según estudios previos de Microsoft y Google, alrededor del 70% de las vulnerabilidades de seguridad están causadas por problemas relacionados con la seguridad de la memoria.

El problema es que no todos los lenguajes propuestos por la Casa Blanca pueden suplir a C/C++ (prueba a crear un sistema operativo con JavaScript) y, que el trabajo ya realizado en dichos lenguajes inseguros no puede portarse de la noche a la mañana (ni de un año para otro) a otros más solventes, como Rust.

Ni siquiera la Fundación Linux, que da soporte a este último lenguaje en su kernel desde hace poco, contempla su uso para algo más que módulos y drivers. Y eso, a pesar de que Linus Torvalds afirma estar convencido de que "en algún momento" presenciará dicho cambio de lenguaje en su kernel.

Ya hace un año, el creador de C++ criticaba un informe de la Agencia Nacional de Seguridad (NSA) estadounidense que defendía la superioridad de los 'lenguajes seguros' como Rust frente a otros como C y C++; dicho informe estaba igualmente centrado en la gestión de memoria, y ha sido, previsiblemente, el desencadenante de la actual decisión de la Casa Blanca.

Bjarne Stroustrup era contundente entonces:

"Si considerase que uno de esos lenguajes 'seguros' es superior a C++ para la gama de usos que me interesan, no vería la desaparición de C/C++ como algo negativo, pero no es el caso. Tal como se describe [por la NSA] 'seguro' se limita a la seguridad de la memoria, dejando de lado una docena de formas distintas en que un lenguaje podría (y será) usado para violar cualquier clase de protección".

Además, según Stroustrup, un analizador estático que cumpla con las directrices básicas de C++ elaboradas durante estos últimos años puede garantizar la seguridad del código... y a un coste mucho menor que el necesario para iniciar una transición de código a nuevos lenguajes.

No hay ciberseguridad sin contemplar el 'quién' además del 'qué'

Este llamamiento es una consecuencia de la creciente preocupación con la ciberseguridad provocada por incidentes como la grave vulnerabilidad Log4j, que expuso las deficiencias en el desarrollo de software crítico, cuando la seguridad de millones de sitios web quedó en manos de sólo tres programadores voluntarios que, trabajando gratis (y quedándose sin dormir) tuvieron que lanzar contrarreloj un parche que después implementarían multitud grandes compañías.

Es por eso que la recomendación de la Casa Blanca no sólo anima a realizar a un cambio en las herramientas de desarrollo, sino que también busca redefinir la responsabilidad en materia de ciberseguridad, para que deje de estar exclusivamente sobre los hombros de pequeños equipos o de programadores individuales y promover que también 'arrimen el hombro' organizaciones más grandes que también se benefician del uso de dicho software (las grandes compañías tecnológicas y, en última instancia, el gobierno).

Fuentes:

https://www.genbeta.com/actualidad/no-c-c-casa-blanca-pide-dejar-usar-lenguajes-programacion-que-base-windows-linux-macos?utm_source=pocket-newtab-es-es