Tente tornar o sudo menos vulnerável a ataques Rowhammer
Uma mudança recente na base de código do `sudo` introduz constantes numéricas especialmente escolhidas com grandes distâncias de Hamming para tornar estados críticos de autorização mais difíceis de inverter por ataques Rowhammer em DRAM. Os comentaristas exploram se esse endurecimento em software vale a pena, dado que Rowhammer é fundamentalmente um problema de confiabilidade de hardware, debatendo trade-offs de complexidade, desempenho e modelos de ameaça do mundo real, e sugerindo alternativas como suporte do compilador, memória ECC e especificações de hardware melhores. O debate também aborda implicações mais amplas para sistemas seguros e resilientes, de sistemas embarcados de alta confiabilidade a hospedagem compartilhada e ambientes de nuvem.
Patch e técnica de codificação
- O sudo agora usa constantes de 32 bits especialmente escolhidas para estados de autenticação (SUCCESS, FAILURE, ERROR, etc.) com grandes distâncias de Hamming entre elas.
- Objetivo: fazer com que sejam necessárias muitas inversões de bits específicas para que o Rowhammer transforme “deny” em “allow”, reduzindo a viabilidade do exploit Mayhem/Rowhammer demonstrado.
- Alguns comentaristas acham esse estilo de codificação defensiva interessante, mas temem que seja um “inferno” aplicá-lo amplamente; outros observam semelhança com ideias de tolerância a falhas давно conhecidas (single-event upsets, votação, ECC).
Ideias de linguagem / compilador
- Vários propõem suporte do compilador: atributos para enums “seguros” cujas codificações maximizem a distância de Hamming, ou modos de hardening que mantenham verificações “redundantes” em vez de otimizá-las para fora.
- Enums em C/C++ são complicados por causa de ABI/compatibilidade retroativa; Rust e linguagens dinâmicas talvez possam oferecer esses recursos com mais facilidade.
- O
hardbooldo GCC é citado como uma ideia análoga para booleanos. - Outros discutem algoritmos para gerar códigos de alta distância; alguns apontam que os valores escolhidos pelo sudo não são matematicamente ótimos, e que construir códigos ótimos é um problema não trivial de teoria da codificação.
Eficácia e trade-offs
- Os defensores enquadram isso como defesa em profundidade: bloqueia diretamente um caminho conhecido do Rowhammer e é apropriado para alvos de alto valor, como binários setuid.
- Os céticos argumentam que isso só protege uma classe de variável, não aborda outros dados/controles corrompíveis e torna o código mais difícil de ler e auditar.
- Alguns observam que, se um invasor já tem execução local de código, pode haver caminhos mais fáceis para escalada; outros respondem que hospedagem compartilhada, clusters e servidores de jogos ainda se beneficiam do hardening.
Rowhammer, ECC e hardware vs software
- Vários comentários enfatizam que Rowhammer é, em essência, um problema de DRAM/física. O debate se divide entre:
- “Corrija no hardware / devolva RAM defeituosa” vs.
- “A física e a densidade tornam a imunidade perfeita irrealista; o software precisa ajudar.”
- ECC e on-die ECC reduzem, mas não eliminam o risco de Rowhammer; ataques sofisticados e inversões de múltiplos bits podem burlar a correção, embora o ECC ao menos deva disparar alertas.
- A DRAM moderna é relatada como mais vulnerável à medida que a densidade aumenta; mitigações do lado do fabricante, como targeted refresh, existem, mas também podem ser imperfeitas ou até exploráveis.
Implicações mais amplas
- O mesmo padrão (codificações de distância máxima, verificações de sanidade) é sugerido para microcontroladores e ambientes de alta radiação, para detectar caminhos de controle inválidos e acionar resets do watchdog.