CVE-2017-15908

What it actually does

A remote DNS server can return a crafted NSEC resource record that triggers an infinite loop inside dns_packet_read_type_window() of systemd-resolved, consuming CPU and denying service to the resolver.

Why it matters to the business

DNS resolution for affected systems can be disrupted, causing application outages and operational delays; the issue appears in a small number of downstream packages and has shown no active exploitation or ransomware use since disclosure more than eight years ago.

How an attack unfolds

An attacker controlling or spoofing a DNS response sends a single malicious NSEC record that systemd-resolved parses in a loop; because the flaw requires no authentication and has remained unexploited in the wild, no named threat actors have been observed leveraging it.

How to fix it

Upgrade ansible/ansible to commit 2a18883cb24b70043b5d719bb3c64c594670cad2 or later; for Alpine v3.7 packages upgrade to ansible 2.4.6.0-r0 or newer; restart systemd-resolved after the update and validate that queries complete normally.

How to confirm the fix worked

Confirm the running systemd version is outside the 223-235 range or that the ansible package matches the listed fixed versions; replay a benign DNS query and verify that resolution latency remains within normal bounds and CPU usage does not spike.

Typical attack path

1. Position a malicious or compromised DNS server in the resolver's upstream path
2. Craft an NSEC resource record that causes dns_packet_read_type_window to loop indefinitely
3. Deliver the record in response to any query from the target systemd-resolved instance
4. Observe sustained CPU consumption and loss of DNS resolution on the affected host

How to detect it

Review systemd-resolved logs and process accounting for sustained high CPU on the resolver process after receiving external DNS replies; correlate with any spikes in query volume or failure rates that lack other explanations.

What your security team should do

• Apply the listed fixed ansible package versions at the next maintenance window
• Monitor upstream systemd-resolved patches and back-port if ansible deployments lag
• Add the fixed package versions to vulnerability scanning policies to prevent regression