Cve-rs: Vulnerabilidades de memória rápidas, escritas em Rust seguro

Artigo original ↗ Discussão no Hacker News ↗

Uma crate Rust de prova de conceito, cve-rs, explora um bug antigo de consistência no compilador, no sistema de lifetimes e variância do Rust, para criar violações de segurança de memória em código que não contém blocos `unsafe`. Os comentadores destrincham como restrições implícitas de lifetime, variância de ponteiros de função e o solucionador de traits atual interagem para permitir esse caso extremo, e observam que Miri consegue detectar o problema mesmo que o rustc aceite o código. A troca avalia quão raros e artificiais esses bugs são em relação ao marketing do Rust como linguagem “segura em memória”, e se casos extremos inconsistentes realmente enfraquecem essa garantia na prática.

Sintaxe de lifetimes em Rust e o bug central

  • A discussão se concentra em como &'a &'b T difere de adicionar uma restrição explícita where 'b: 'a.
  • Vários comentários explicam: referências aninhadas criam restrições de lifetime implícitas que o compilador deveria respeitar; o lifetime externo não deve sobreviver ao interno.
  • O bug surge quando essas restrições implícitas interagem com a variância de ponteiros de função e lifetimes de ordem superior: o compilador pode inferir incorretamente que um lifetime sobrevive a outro após certos casts, permitindo um use-after-free em código “seguro”.
  • Alguns enfatizam que isso diz respeito a lifetimes com vínculo tardio vs. vínculo precoce e a como a variância (contra-/covariância) é tratada para tipos de função.

Miri, Polonius e trabalho no solucionador de traits

  • Miri (um interpretador/sanitizer) detecta a inconsistência em tempo de execução, mesmo quando o código Rust é sintaticamente “seguro”.
  • Há debate sobre se um novo solucionador de traits e refatorações relacionadas (restrições implícitas, coindução) são pré-requisitos para uma correção adequada; links observam que este bug está explicitamente bloqueado por esse trabalho.
  • Alguns são céticos em relação à narrativa de que “o novo solucionador vai corrigir isso”, mas outros observam que há um plano técnico claro, apenas difícil e lento.

Garantias de segurança, inconsistência e marketing

  • Um lado argumenta: mesmo com mais de 80 problemas abertos de “inconsistência”, Rust é muito mais seguro do que C/C++, e esses são casos extremos raros, muitas vezes difíceis de atingir por acidente.
  • Outros contrapõem: qualquer inconsistência enfraquece as alegações de “segurança de memória”; Rust deveria ser descrito como “mais seguro em memória” até que esses bugs sejam corrigidos.
  • Há discussão sobre se isso é um bug do compilador ou uma falha mais profunda da teoria da linguagem/tipos; alguns insistem que o design pode ser tornado consistente, mas a implementação está atrasada.

Ergonomia e facilidade de aprendizado

  • Alguns leitores acham o código que dispara o bug assustador ou ilegível e se preocupam que Rust seja “muito simbólico” e gere RSI.
  • Outros respondem que esse é um código obscurecido, no estilo repro mínimo, e não representa o Rust típico; a maioria do código real tem poucos lifetimes explícitos.
  • Lifetimes são explicados informalmente como “pools de memória” com rótulos, o que vários consideram esclarecedor.
  • Há críticas e defesa mais amplas das escolhas sintáticas de Rust, com sugestões de que alguma sintaxe relacionada a unsafe e a sintaxe de funções poderiam ter sido projetadas melhor.

Impacto prático e explorabilidade

  • Muitos enfatizam que explorar isso exige código artificial e truques anti-otimização; é improvável que seja escrito por acidente.
  • Ainda assim, comentadores observam que mesmo um único buraco desses contradiz a expectativa de que código Rust seguro não possa causar corrupção de memória, e deve ser levado a sério.
  • Faz-se comparação com outros caminhos como /proc/self/mem, com a lembrança de que as garantias do Rust cobrem apenas o que o próprio programa faz, e não processos externos ou o sistema operacional.

Miscelânea

  • O licenciamento de brincadeira do projeto (GLWTS) e uma função download_more_ram() são observados como toques bem-humorados.
  • Alguém pergunta sobre o prompt do shell; outros o identificam como uma ferramenta popular de prompt.