Cve-rs: Vulnerabilidades de memoria rápidas, escritas en Rust seguro

Sintaxis de lifetime de Rust y el error central

• La discusión se centra en cómo &'a &'b T difiere de añadir un bound explícito where 'b: 'a.
• Varios comentarios explican: las referencias anidadas crean restricciones de lifetime implícitas que el compilador debería respetar; el lifetime externo no debe sobrevivir al interno.
• El error surge cuando estas restricciones implícitas interactúan con la varianza de los punteros a función y los lifetimes de mayor rango: el compilador puede asumir incorrectamente que un lifetime sobrevive a otro después de ciertos casts, habilitando un use-after-free en código “seguro”.
• Algunos enfatizan que esto trata de lifetimes de enlace tardío frente a enlace temprano y de cómo se maneja la varianza (contra-/covarianza) para tipos de función.

Miri, Polonius y el trabajo del solver de traits

• Miri (un intérprete/sanitizador) detecta la falta de solidez en tiempo de ejecución, incluso cuando el código Rust es sintácticamente “seguro”.
• Hay debate sobre si un nuevo solver de traits y refactors relacionados (implícitos bounds, coinducción) son prerrequisitos para una solución adecuada; los enlaces señalan que este bug está explícitamente bloqueado por ese trabajo.
• Algunos se muestran escépticos ante la narrativa de “el nuevo solver lo arreglará”, pero otros señalan que hay un plan técnico claro, aunque difícil y lento.

Garantías de seguridad, falta de solidez y marketing

• Una parte argumenta: incluso con más de 80 issues abiertos de “unsound”, Rust es mucho más seguro que C/C++, y estos son casos límite raros, a menudo difíciles de provocar por accidente.
• Otros replican: cualquier falta de solidez socava las afirmaciones de “seguridad de memoria”; Rust debería describirse como “más seguro en memoria” hasta que estos errores se arreglen.
• Hay discusión sobre si esto es un bug del compilador o un fallo más profundo de teoría de tipos/lenguaje; algunos insisten en que el diseño puede hacerse sólido, pero la implementación va por detrás.

Ergonomía y facilidad de aprendizaje

• A algunos lectores les parece aterrador o ilegible el código que dispara el error y les preocupa que Rust sea demasiado “cargado de símbolos” e induzca RSI.
• Otros responden que esto es código ofuscado, de reproducción mínima, no representativo del Rust típico, y que en la mayor parte del código real hay pocos lifetimes explícitos.
• Los lifetimes se explican informalmente como “pools de memoria” con etiquetas, lo que varios encuentran aclarador.
• Hay una crítica y defensa más amplia de las elecciones sintácticas de Rust, con sugerencias de que parte de la sintaxis relacionada con unsafe y la sintaxis de funciones podría haberse diseñado mejor.

Impacto práctico y explotabilidad

• Muchos subrayan que explotar esto requiere código artificioso y trucos anti-optimización; es poco probable que se escriba accidentalmente.
• Aun así, comentan que incluso un solo agujero así contradice la expectativa de que el código Rust seguro no puede causar corrupción de memoria, y debe tomarse en serio.
• Se hace una comparación con otras vías como /proc/self/mem, con el recordatorio de que las garantías de Rust solo cubren lo que hace el propio programa, no procesos externos ni el sistema operativo.

Miscelánea

• Se mencionan como detalles humorísticos la licencia de broma del proyecto (GLWTS) y una función download_more_ram().
• Alguien pregunta por el prompt de la shell; otros lo identifican como una herramienta de prompt popular.