Try to make sudo less vulnerable to Rowhammer attacks

Original Article ↗ Hacker News Discussion ↗

A recent change to the `sudo` codebase introduces specially chosen numeric constants with large Hamming distances to make critical authorization states harder to flip via Rowhammer-style DRAM attacks. Commenters explore whether such software-level hardening is worthwhile given that Rowhammer is fundamentally a hardware reliability problem, debating trade-offs in complexity, performance, and real-world threat models, and suggesting alternatives like compiler support, ECC memory, and better hardware specifications. The thread also touches on broader implications for secure and resilient system design, from high-reliability embedded systems to shared hosting and cloud environments.

Patch and coding technique

  • Sudo now uses specially chosen 32‑bit constants for auth states (SUCCESS, FAILURE, ERROR, etc.) with large Hamming distances between them.
  • Goal: make it require many specific bit flips for Rowhammer to turn “deny” into “allow,” reducing feasibility of the demonstrated Mayhem/Rowhammer exploit.
  • Some commenters find this style of defensive coding interesting but worry it would be “hell” to apply broadly; others note similarity to long‑known fault‑tolerance ideas (single‑event upsets, voting, ECC).

Language / compiler ideas

  • Several propose compiler support: attributes for “secure” enums whose encodings maximize Hamming distance, or hardening modes that keep “redundant” checks instead of optimizing them away.
  • C/C++ enums are tricky due to ABI/backwards compatibility; Rust and dynamic languages might support such features more easily.
  • GCC’s hardbool is cited as an analogous idea for booleans.
  • Others discuss algorithms for generating high‑distance codes; some point out sudo’s chosen values are not mathematically optimal, and constructing optimal codes is a nontrivial coding‑theory problem.

Effectiveness and trade‑offs

  • Supporters frame this as defense‑in‑depth: it directly blocks a known Rowhammer path and is appropriate for high‑value targets like setuid binaries.
  • Skeptics argue it only protects one variable class, doesn’t address other corruptible control/data, and makes code harder to read and audit.
  • Some note that if an attacker already has local code execution, there may be easier escalation paths, though others counter that shared hosting, clusters, and game servers still benefit from hardening.

Rowhammer, ECC, and hardware vs software

  • Multiple comments stress Rowhammer is fundamentally a DRAM/physics problem. Debate splits between:
    • “Fix it in hardware / return defective RAM” vs.
    • “Physics and density make perfect immunity unrealistic; software must help.”
  • ECC and on‑die ECC reduce but do not eliminate Rowhammer risk; sophisticated attacks and multi‑bit flips can bypass correction, though ECC should at least trigger alerts.
  • Modern DRAM is reported to be more vulnerable as density increases; vendor‑side mitigations like targeted refresh exist but can themselves be imperfect or even abused.

Broader implications

  • The same pattern (max‑distance encodings, sanity checks) is suggested for microcontrollers and high‑radiation environments to detect invalid control paths and trigger watchdog resets.