Rust es el lenguaje de programación más querido por quinta vez. ¿Es nuestro nuevo salvador de la seguridad?

Durante los últimos años, parece que los ingenieros de software de todo el mundo no se cansan de programar en Rust. Este lenguaje de programación de sistemas relativamente nuevo, creado por Mozilla, se ha ganado el corazón de la comunidad de Stack Overflow y, tratándose de un grupo poco dado a tonterías, cuando votan algo como el "lenguaje de programación más querido" cinco años seguidos, es hora de que todos prestemos atención.

El lenguaje de programación Rust incorpora elementos conocidos y funcionales de lenguajes de uso común, trabajando bajo una filosofía diferente que elimina la complejidad a la vez que introduce rendimiento y seguridad. Tiene una curva de aprendizaje y muchos desarrolladores no tienen la oportunidad de experimentar mucho con él: solo el 5,1 % de los encuestados en Stack Overflow lo utilizaba habitualmente. Aun así, no se puede negar que es un lenguaje emocionante y con mucha más potencia de seguridad que sus predecesores, como C y C++. La adopción masiva requerirá cambios, tanto de comportamiento como tecnológicos... pero, por ahora, sigue captando la atención de los desarrolladores a nivel teórico.

...pero un momento, debemos destacar algo más: es importante señalar que Rust es un lenguaje de programación que prioriza la seguridad de la memoria y la erradicación de errores de seguridad vinculados a problemas comunes de gestión de memoria. Estos son un gran problema (y sin duda causan más de un dolor de cabeza a los equipos de seguridad de aplicaciones), pero no son los únicos desafíos de codificación segura a los que nos enfrentamos.

¿Qué previene exactamente Rust? ¿Y dónde seguimos expuestos en el panorama de la seguridad? Analicemos el último unicornio de la programación:

La nueva frontera de la programación de sistemas moderna y segura para la memoria

El equipo de investigación y desarrollo de Mozilla ha trabajado en proyectos increíbles, e invertir en la programación en Rust como pionero de código abierto no es una excepción. Su vídeo de presentación ofrece una visión de su filosofía, dejando claro el tema principal: el enfoque actual de la seguridad del software es defectuoso y Rust está diseñado para resolver gran parte de ese problema.

Parece demasiado simplista, sobre todo porque nos enfrentamos a enormes brechas de datos cada dos por tres, como el reciente y terrible error reportado por EasyJet. Millones de registros de datos se ven comprometidos con frecuencia, casi siempre debido a una vulnerabilidad de la aplicación web, una configuración de seguridad incorrecta o un ataque de phishing, y lenguajes como C++ existen desde hace décadas. Sin embargo, este tiempo no ha sido suficiente para que los desarrolladores los dominen hasta el punto de implementar las mejores prácticas de codificación segura. ¿Por qué Rust iba a ser diferente? Han aparecido nuevos lenguajes antes y no es que hayan encontrado la forma de erradicar las vulnerabilidades comunes o de garantizar que cualquier código escrito sea mágicamente perfecto al compilarse.

Por muy simple que sea el concepto, a veces son las respuestas sencillas las que resuelven preguntas complejas. Rust es, en todo el sentido de la palabra, una revolución en la programación de sistemas segura para la memoria que cumple sus promesas de muchas maneras... y sin duda salva el pellejo a los desarrolladores propensos a introducir errores que pueden causar grandes problemas si no se detectan. Java, C, C++ e incluso lenguajes más nuevos como Kotlin y Golang siguen siendo bastante implacables con el desarrollador que no tiene conocimientos de seguridad. Con ellos, no hay advertencias integradas, ni señales particulares de que la fantástica función que se acaba de compilar tenga un gremlin de seguridad escondido bajo el capó.

Así que, profundicemos:

¿Qué hace que Rust sea tan seguro?

Normalmente, el objetivo principal de un desarrollador es crear funciones, asegurándose de que sean funcionales y fáciles de usar; tal vez incluso fuentes de orgullo que le gustaría mostrar en su currículum. Es totalmente normal que un desarrollador cree un gran software, lo publique y pase al siguiente gran proyecto. En este punto, los equipos de seguridad comprueban si hay vulnerabilidades y, si las encuentran, su aplicación "terminada" podría volver al equipo para una corrección rápida. El problema puede ser sencillo o puede estar completamente fuera del alcance razonable para que un desarrollador lo solucione.

El problema es que, a nivel superficial, los errores de seguridad no eran evidentes en absoluto y, si el escaneo, las pruebas y la revisión manual del código no los detectan, un atacante puede aprovechar esa pequeña ventana de oportunidad para explotar el error.

Ahora, Rust busca evitar que muchas vulnerabilidades lleguen al código en primer lugar: simplemente no se compila si hay errores de sintaxis u otros errores de seguridad de memoria que causan problemas de producción a lo largo del ciclo de vida de desarrollo de software (SDLC). Se trata de una programación segura para la memoria por diseño, que garantiza que no haya acceso a memoria no válida (independientemente de cómo se ejecute el software). Y con el 70 % de todos los errores de seguridad derivados de problemas relacionados con la gestión de la memoria, esto es un gran logro.

Rust señalará y evitará:

• Desbordamiento de búfer
• Uso después de liberación
• Doble liberación
• Desreferencia de puntero nulo
• Uso de memoria no inicializada

Si comparamos un fragmento de código en Rust con uno en C++, quedará claro que el primero es seguro por defecto. Echa un vistazo a este ejemplo de un error de desbordamiento de búfer:

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // desbordamiento de búfer ya que la longitud de b es mayor que la de a
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust lanza una advertencia de seguridad y entra en pánico al llegar a la función copy_from_slice en tiempo de ejecución para evitar el desbordamiento de búfer, pero no lo hace en tiempo de compilación.

En ese sentido, es en gran medida uno de los lenguajes que "empiezan por la izquierda". Resalta los errores y enseña a los desarrolladores la forma correcta de escribir código para evitar introducir fallos de seguridad relacionados con la memoria, por lo que cumplir los plazos depende de que el programador preste atención, corrija y se mantenga fiel a la ruta de entrega.

El enfoque de este lenguaje parece sencillo, pero habría sido una hazaña increíble lograr que funcionara con esta lógica tan potente, y realmente cumple lo que promete. Rust es, desde una perspectiva de seguridad, un gran salto adelante... si tan solo más gente lo utilizara. Empresas como Dropbox son pioneras en su uso a gran escala corporativa, y es fantástico verlo. Sin embargo, hay más consideraciones antes de saltar a la conclusión de que un problema de adopción es lo único que nos separa de un futuro más seguro.

El ajuste de cuentas de Rust.

Existen un par de problemas pequeños (vale, grandes), concretamente que programar en Rust tiene más margen para introducir errores de lo que parece. No solucionará las importantísimas vulnerabilidades del Top 10 de OWASP que siguen provocando brechas, retrasos y una cultura general de técnicas de codificación inseguras. También existe una dinámica de ángel y demonio, o, como se conoce más ampliamente: Rust seguro frente a Rust inseguro.
‍

Como se explica en la documentación oficial, el Rust seguro es la forma "verdadera" de Rust, y el Rust inseguro incluye funciones que se consideran "definitivamente no seguras", aunque a veces son necesarias, como cuando se requiere la integración con algo en otro lenguaje. Sin embargo, incluso con el Rust inseguro, la lista de funcionalidades adicionales sigue siendo limitada. En el Rust inseguro, es posible hacer lo siguiente dentro de bloques inseguros:

• Desreferenciar punteros sin procesar
• Llamar a funciones inseguras (incluidas funciones de C, intrínsecos del compilador y el asignador sin procesar)
• Implementar rasgos inseguros
• Mutar estáticos
• Acceder a campos de uniones.

Incluso en el llamado modo "inseguro", uno de los superpoderes de la programación en Rust sigue funcionando: el "comprobador de préstamos" (borrow checker). Por lo general, evita problemas de memoria, colisiones en cálculos paralelos y muchos otros errores mediante el análisis estático de código, y este análisis seguirá realizando comprobaciones en un bloque inseguro; simplemente requiere mucho más trabajo escribir construcciones inseguras sin que el compilador intervenga con orientación en ciertas situaciones.

Esto no parece un gran problema para la mayoría de los desarrolladores experimentados —después de todo, somos conocidos por trastear para sacar el máximo partido a nuestras aplicaciones y abrir algunas funciones más interesantes—, pero potencialmente abre un agujero negro que puede conducir a graves errores de configuración y vulnerabilidades de seguridad: el comportamiento indefinido. Programar en Rust (incluso cuando se usa de forma insegura) limita bastante las posibilidades de vulnerabilidades en comparación con C o C++, pero invocar un comportamiento indefinido puede ser un riesgo.

¿Es este el fin de la dependencia de la codificación segura dirigida por el desarrollador?

¿Recuerdas cuando dije antes que Rust tiene componentes de lenguajes conocidos? Una de las principales vulnerabilidades de seguridad de Rust es que, bueno, tiene componentes de lenguajes conocidos, concretamente C.

Rust sigue siendo un "lenguaje de programación seguro", pero, de nuevo, la introducción de un usuario es donde las cosas pueden torcerse. El desarrollador todavía puede ajustarlo para que se ejecute sin marcar errores (una propuesta atractiva, ya que esto desbloquea más capacidades) y, esencialmente, incluso en un estado seguro, los desarrolladores pueden seguir siendo tan "inseguros" como quieran, porque tienen una capa de orientación y protección antes de que las cosas puedan salir realmente mal.

Y ambos escenarios anteriores se vuelven más peligrosos a medida que profundizamos, ya que los resultados de Rust son similares a las herramientas de escaneo: al igual que no existe una herramienta suiza SAST/DAST/RAST/IAST que escanee todas las vulnerabilidades, todos los vectores de ataque y todos los problemas, Rust tampoco lo hace. Incluso con Rust algunas vulnerabilidades pueden introducirse con bastante facilidad.

El riesgo de comportamiento indefinido al ejecutar Rust inseguro tiene el potencial de abrir problemas de desbordamiento de enteros, mientras que, en general, incluso las configuraciones seguras no evitarán el error humano en configuraciones de seguridad incorrectas, lógica de negocio o el uso de componentes con vulnerabilidades conocidas. Estos problemas siguen representando una amenaza muy real si no se parchean, y en un entorno "supuestamente seguro" como el Rust real, puede incluso causar cierto comportamiento complaciente si un programador cree que todos los problemas importantes se detectarán de todos modos.

He descubierto que Rust no es diferente a un mentor de programación: un ingeniero senior que se ha tomado el tiempo de sentarse con un programador menos experimentado, revisando su trabajo y mostrándole posibles errores, señalando eficiencias y, en algunos casos, asegurándose de que no se compile hasta que esté bien. Sin embargo, es mucho mejor que los programadores de Rust aprendan la teoría y se comprometan ellos mismos con las mejores prácticas, ya que ese mentor podría cortar el cordón umbilical y no querrás quedarte colgado.

¿Listo para encontrar y corregir vulnerabilidades comunes de Rust ahora mismo? Juega al desafío.