La lucha por lenguajes de programación más seguros

En diciembre de 2023, agencias de seguridad de cinco regiones, incluyendo América del Norte, Europa y el Pacífico Sur, publicaron un documento instando a los líderes de las empresas de software a hacerse cargo de la seguridad del software que crean. Esto fue resaltado aún más por la Casa Blanca en febrero de 2024 cuando publicaron un esquema de ciberseguridad. Este artículo va a ver los lenguajes de programación seguros mencionados en esos documentos, comparar su seguridad con Erlang y Elixir, y presentar un nuevo concepto conocido como impedancia insegura.

#La Necesidad de Lenguajes de Programación Seguros

Las agencias de seguridad dijeron que incluso los desarrolladores más habilidosos pueden introducir errores, lo que lleva a serias brechas de seguridad. Recomendaron que las empresas se alejen de lo que llaman lenguajes inseguros en memoria hacia lo que denominan Lenguajes Seguros en Memoria (MSLs). Estas agencias enfatizaron que todos los creadores de software, no solo aquellos que venden software, deben desarrollar y publicar planes para mostrar cómo asumirán la responsabilidad de la seguridad de sus productos.

El informe sostiene que, aunque muchos lenguajes de programación se consideran "seguros," todavía pueden permitir que se escriba código inseguro. Si se utiliza código inseguro, la seguridad del producto se ve comprometida. Esto lleva a la idea de impedancia insegura, que ayuda a evaluar con qué facilidad se puede escribir código inseguro en diferentes lenguajes de programación.

#Definiendo la Impedancia Insegura

La impedancia insegura se refiere al nivel de dificultad que enfrenta un programador al tratar de escribir código inseguro en un lenguaje de programación. Los lenguajes con alta impedancia insegura hacen que sea más difícil escribir código inseguro, mientras que los de baja impedancia insegura lo hacen más fácil. Este concepto puede ayudar tanto a expertos técnicos como a líderes empresariales a elegir lenguajes de programación seguros y a desarrollar sus planes de seguridad.

#Seguro por Diseño y Seguro por Defecto

En 2023, trece agencias de seguridad globales delinearon lo que consideraban productos "seguros por diseño" y "seguros por defecto." Para que un producto tecnológico sea seguro por diseño, debe estar construido para prevenir el acceso no autorizado de manera efectiva. Seguro por defecto significa que el producto debería ser resistente a técnicas de explotación comunes sin requerir costos adicionales.

Al mirar los lenguajes de programación, los podemos categorizar en estos términos. Los lenguajes que inherentemente protegen contra vulnerabilidades se consideran seguros por defecto. Sin embargo, muchos lenguajes de programación comunes permiten que se escriba código inseguro y aún así no cumplen con este frente.

#Problemas Comunes de Seguridad de Memoria

Hay dos tipos principales de vulnerabilidades de memoria: espaciales y temporales.

• Vulnerabilidades espaciales surgen de cómo se utilizan las ubicaciones de memoria.
• Vulnerabilidades temporales ocurren debido a problemas de tiempo que pueden llevar a errores de memoria.

Aquí hay algunos ejemplos:

Problemas de Memoria Espacial:

• Desbordamiento de búfer
• Índice de arreglo fuera de límites

Problemas de Memoria Temporal:

• Uso después de liberar
• Fugas de memoria

Las agencias de seguridad incluirán varios lenguajes en su lista de lenguajes seguros en memoria, como C, Go, Java, Python, Rust y Swift. Sin embargo, ninguno de estos lenguajes es seguro por defecto, ya que permiten que se escriba código inseguro.

#Evaluando Código Inseguro en Lenguajes Populares

Cada lenguaje de programación tiene reglas respecto al código inseguro.

1. Lenguaje C: C permite código inseguro sin ningún indicador claro de que el código es inseguro, lo que lo hace muy fácil de escribir.

2. Go: En Go, un programador puede crear punteros inseguros sin ninguna advertencia visual. Aunque el paquete inseguro de Go existe como una opción, su uso no es obligatorio.

3. Java: Java permite código inseguro a través de su Interfaz Nativa (JNI). Una vez que se ejecuta código inseguro, no hay una indicación clara de que un comportamiento inseguro está ocurriendo.

4. Python: Usando la biblioteca ctypes, Python puede interactuar con código inseguro de otros lenguajes. La falta de indicadores directos puede llevar a problemas de seguridad.

5. Rust: Aunque Rust incluye una palabra clave insegura para resaltar código inseguro, aún permite operaciones inseguras en el mismo espacio de memoria que el código seguro.

6. Swift: Swift tiene indicadores claros para el código inseguro, pero eso no previene que ocurran acciones inseguras al interactuar con otros lenguajes.

#Cómo Destacan Erlang y Elixir

Erlang y Elixir son únicos ya que corren en la máquina virtual BEAM. Este entorno tiene sus vulnerabilidades, pero ambos lenguajes no permiten el uso directo de punteros, lo que reduce significativamente los problemas comunes de memoria. Están diseñados para ser seguros por defecto, pero aún pueden ser comprometidos al usar Funciones Implementadas Nativamente (NIFs).

#Presentando el Proceso de Aceptación Insegura (UAP)

Para promover prácticas de software más seguras, proponemos un Proceso de Aceptación Insegura (UAP) para las empresas. Este proceso debería superar los obstáculos para usar código inseguro requiriendo:

• Justificación de la necesidad de un NIF.
• Una descripción de los riesgos de seguridad que vienen con la implementación del NIF.
• Código fuente para las funciones inseguras propuestas.
• Evidencia que muestre que el NIF no introduce comportamientos inseguros.
• Beneficios de velocidad propuestos al usar el NIF.
• Soluciones alternativas que podrían funcionar sin usar NIFs.

El UAP debería prevenir que cualquier desarrollador añada código inseguro a las aplicaciones de manera independiente. Debería exigir una evaluación exhaustiva y escepticismo hacia la adición de cualquier NIF.

#Hacia un Software Más Seguro

Cada sistema, ya sea basado en un lenguaje seguro por defecto como Erlang o Elixir, corre el riesgo de ser atacado si se introduce código inseguro. Históricamente, muchas organizaciones han priorizado la facilidad de usar código inseguro para superar limitaciones de rendimiento o reutilizar código existente. Sin embargo, en el mundo actual, donde la seguridad es cada vez más primordial, es esencial priorizar la seguridad sobre la velocidad.

Los riesgos asociados con el código inseguro son significativos, con muchos incidentes, como la vulnerabilidad Heartbleed en OpenSSL, destacando cuán peligrosas pueden ser tales prácticas. Las organizaciones deben adaptarse a esta realidad y buscar eliminar código inseguro siempre que sea posible.

#Investigación y Direcciones Futuras

Se necesita un mayor examen para comprender completamente y mejorar las formas en que los lenguajes de programación pueden ser seguros por defecto. La investigación también debería explorar métricas para medir la impedancia insegura y evaluar varios lenguajes de programación de manera más rigurosa.

En resumen, el futuro de la seguridad del software radica en combinar lenguajes seguros con prácticas empresariales robustas. Al poner énfasis en los procesos de aceptación insegura, las organizaciones pueden fomentar un entorno de codificación más seguro. Este enfoque beneficia a todos, asegurando que el desarrollo de software priorice la seguridad y la resiliencia ante amenazas crecientes.