CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

Original Article ↗ Hacker News Discussion ↗

Newly disclosed CERT advisories detail six serious vulnerabilities in dnsmasq, a lightweight DNS/DHCP server embedded in millions of routers and Linux systems, raising concerns about remote code execution, denial-of-service, and man‑in‑the‑middle attacks on home and IoT networks. Commenters focus on the difficulty of patching widely deployed firmware (e.g., OpenWRT, DD‑WRT, LXD setups) and debate the merits of Debian’s conservative backporting model versus faster-moving distros when responding to such flaws. The wave of AI-assisted vulnerability discovery and the C-based codebase of core networking tools fuel broader calls for rewrites in memory-safe languages like Rust or Go, alongside mention of smaller alternative DNS servers that claim stronger security records.

Vulnerability impact and real‑world risk

  • Commenters see these dnsmasq bugs as serious, especially because it’s embedded in many devices that rarely get updates.
  • Attackers who compromise a home router can:
    • MITM non‑encrypted traffic and SSH sessions where users blindly accept keys.
    • Block OS/app update endpoints to keep internal machines vulnerable, then attack them.
    • Abuse the router as a proxy, VPN exit, or DDoS node, and target IoT devices.
  • Specific flaws mentioned include heap overflows, integer underflow, and infinite loops that can halt DNS responses.

Routers, OpenWRT, and embedded devices

  • People worry about consumer routers and embedded gear that won’t be patched or are hard to flash.
  • OpenWRT and DD‑WRT are reported as actively working on or already integrating fixes, but new builds are not all out yet.

Debian’s handling of dnsmasq and “stable”

  • Large subthread debates Debian’s model:
    • Critics call the dnsmasq in stable “embarrassingly ancient” and object to heavy backporting, arguing it’s resource‑intensive, discourages refactoring, and often leaves non‑security bugs unfixed for years.
    • Defenders say stable is intentionally conservative: only minimal security/bug patches, major feature updates via testing/unstable every ~2 years, and optional backports/third‑party repos for newer stacks.
    • Some argue this approach is vital for big orgs and “set and forget” machines; others see it as deferred maintenance that leads to painful mass upgrades.

AI‑generated CVEs and security audits

  • Multiple comments note a “tsunami” of AI‑assisted bug reports; maintainers expect repeated patch cycles as tools keep finding new issues.
  • Some projects reportedly see many AI‑found bugs; others (e.g., certain DNS and mail servers) claim none or very few, attributing that to stricter design and smaller, more carefully written codebases.
  • Debate on whether less‑popular software has fewer bugs or just less scrutiny; AI is seen as lowering the cost of auditing even obscure projects.

C vs memory‑safe languages and rewrites

  • Several argue this is a tipping point to replace C infrastructure with Rust/Go for DNS/DHCP, given the dominance of memory‑safety bugs.
  • Others counter that rewrites are risky and can introduce many new logic and OS‑level bugs, citing a Rust coreutils replacement with dozens of CVEs.
  • Some propose using AI more for auditing and for assisting partial rewrites, rather than full greenfield replacements.

Design and alternatives

  • Some dislike dnsmasq’s “does everything” design, preferring separate DNS/DHCP/TFTP daemons; others value its integration for small routers.
  • Alternatives like MaraDNS are discussed, with claims of strong security records and heavy auditing, but criticism over self‑promotion and smaller adoption.