[Bug network/27929] New: Lax stub resolver interpretation of ServFail allows DNSSEC bypass

[Bug network/27929] New: Lax stub resolver interpretation of ServFail allows DNSSEC bypass

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=27929

            Bug ID: 27929
           Summary: Lax stub resolver interpretation of ServFail allows
                    DNSSEC bypass
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

When a query for both IPv4 and IPv6 records is performed, glibc's stub resolver
will treat ServFail for one of the two as equivalent to nonexistence (NODATA)
as long as the other succeeds (and has data? not sure if this happens if it's
NODATA). This creates an opportunity for an attacker to silently forge
nonexistence of one or the other in an environment where the user has
DNSSEC-validating nameservers and (rightly) expects all results for signed
zones to be authentic.

I became aware of this behavior because a musl libc user shipping software
linked to musl found that musl's stub resolver failed in an environment where
glibc's was succeeding, and the underlying cause was a buggy consumer-router
product returning ServFail in place of NODATA. I'm reaching out the the vendor
to get that fixed, but I suspect glibc is doing this intentionally for
compatibility with broken nameservers like the ones we encountered. However, I
don't think there's been consideration of how this lax interpretation of
results impacts the integrity of results in an environment with DNSSEC
validation.

The behavior probably needs to be made optional and documented.

Multiple other stub resolver implementations were found to have the same
behavior here. As this undermines DNSSEC, I would like to pursue a CVE
assignment for the issue across multiple stub resolvers. I believe having this
recognized as a vulnerability would aid in convincing vendors with buggy
nameservers to fix them.

Real world impact is probably fairly low, which is why I've reported publicly
rather than through private security channels. I don't believe it's possible to
completely forge nonexistence of the name, only of one or the other address.
This could still have nontrivial security impact in the event that the address
families have routing with different privacy or cost properties, or if results
are filtered for family such that the end result is an apparently-validated
nonexistence for the name rather than a lookup failure.

-- 
You are receiving this mail because:
You are on the CC list for the bug.