El caso a favor de hojas de ruta seguras para la memoria

Artículo original ↗ Discusión en Hacker News ↗

Las orientaciones de seguridad de la NSA y socios internacionales que impulsan un cambio hacia lenguajes “seguros para la memoria” han reavivado el debate sobre cómo reducir vulnerabilidades de software arraigadas en C y C++. Los comentaristas evalúan la practicidad de adoptar de forma incremental Rust y otros lenguajes más seguros frente a enormes bases de código heredado, dominios críticos para el rendimiento y ecosistemas como gráficos o kernels profundamente ligados a C/C++. Muchos sostienen que la elección del lenguaje, herramientas sólidas y cambios arquitectónicos (p. ej., microkernels, sandboxing) deben complementar la formación de los desarrolladores, ya que incluso programadores muy capacitados tienen dificultades para evitar a escala los errores de seguridad de memoria.

Adopción de lenguajes seguros para la memoria en código de sistemas/SO

  • La discusión se centra en cómo llevar la seguridad de memoria a kernels y sistemas de bajo nivel.
  • Rust en el kernel de Linux se ve como prometedor, pero todavía es diminuto en alcance y de etapa temprana, sobre todo en controladores.
  • La estrategia preferida: convertir gradualmente componentes de “borde” a Rust en lugar de reescrituras.
  • Algunos sostienen que los microkernels o una segmentación intensa (VMs, aislamiento al estilo Qubes) habrían resuelto gran parte de esto antes.

Elecciones de lenguaje y la “lista segura” de la NSA

  • El apéndice de la NSA enumera C#, Go, Java, Python, Rust y Swift como “seguros para la memoria”, lo que desató el debate.
  • Muchos señalan que los ecosistemas del mundo real a menudo llaman a bibliotecas C/C++, lo que socava la seguridad práctica.
  • Algunos se preguntan por qué Python figura pero no Ruby, JS o Perl; la explicación que se sugiere: popularidad e impulso en IA/ML.

Rust vs C/C++ (y Go/Swift)

  • Los defensores enfatizan “seguro por defecto, inseguro en regiones pequeñas y explícitas” de Rust, reduciendo la superficie de auditoría.
  • Los críticos dicen que para trabajo de bajo nivel se topan con unsafe y MaybeUninit con frecuencia, sintiéndolo como C con más ceremonia.
  • Los defensores de C++ sostienen que RAII, punteros inteligentes, tipos enteros personalizados, sanitizers y subconjuntos disciplinados pueden ser “lo bastante seguros”, pero otros responden que la historia muestra que los humanos siguen introduciendo errores críticos.
  • Se señala que Go y Swift son seguros para la memoria a nivel de lenguaje, pero con matices: Go tiene exploits basados en carreras de datos; Swift y Rust añaden garantías de concurrencia más fuertes.

Otros lenguajes: Ada, Fortran, Java, JavaScript, Python

  • Ada/SPARK se citan como fuertemente seguros para la memoria en dominios críticos para la seguridad (aviónica, ferrocarril, defensa), pero con una cuota de mercado diminuta.
  • Fortran queda en gran medida confinado a la computación científica; no se lo ve como una gran superficie de ataque.
  • Java es llamado tanto un “pest fest” para exploits como, por otros, mayormente aceptable salvo incidentes notables (p. ej., log4j).
  • Los motores de JavaScript son difíciles de hacer completamente seguros debido a la complejidad del JIT; algunos mencionan implementaciones más seguras en la JVM.
  • Python en sí es seguro para la memoria, pero la dependencia de extensiones C/C++ reintroduce riesgo.

Concurrencia, comportamiento indefinido y límites de la seguridad

  • Varios sostienen que, después de la seguridad de memoria, el comportamiento indefinido y el desbordamiento/subdesbordamiento de enteros deberían ser los siguientes objetivos.
  • Se elogia el comportamiento definido de desbordamiento de Rust (panic en debug, wrap en release, además de APIs verificadas explícitas).
  • Otros señalan que ningún lenguaje “resuelve” por completo la concurrencia; Rust y Swift llegan más lejos, pero las carreras lógicas persisten.

Código heredado, formación y herramientas

  • El enorme legado de C/C++ se ve como el problema central. Muchos sistemas nuevos siguen comenzándose en estos lenguajes.
  • Algunos proponen subconjuntos más estrictos (estilo MISRA) y análisis estático (Astree, Frama-C, etc.) para demostrar seguridad, pero señalan el costo y la dificultad.
  • El hilo es escéptico respecto a que la formación por sí sola pueda prevenir errores de memoria; incluso desarrolladores altamente capacitados en dominios regulados siguen cometiéndolos.
  • Se sugiere que la IA podría ser un asistente futuro para auditar C/C++ en busca de problemas de memoria, en lugar de escribir código nuevo.

Modelos de amenaza, aislamiento y motivaciones de la NSA

  • Los participantes subrayan que el código C sin conexión o “offline” no es inmune (se cita Stuxnet); si parece necesario aislarlo, entonces los lenguajes seguros para la memoria probablemente también lo sean.
  • Algunos sugieren cínicamente que la NSA quiere que la industria se mueva a runtimes compartidos que podría atacar, mientras otros responden que la NSA también tiene fuertes incentivos para endurecer la infraestructura de EE. UU.