Date: Thu, 13 Nov 2014 15:56:28 +0100 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com, krahmer@...e.de CC: cve-assign@...re.org Subject: Re: Re: CVE-request: systemd-resolved DNS cache poisoning On 11/12/2014 06:33 PM, cve-assign@...re.org wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> systemd-resolved contains a caching resolver ... does not implement >> any of the hardening recommendations of rfc5452. > > We have several comments about this. First, systemd-resolved is > apparently advertised as a stub resolver (e.g., see the > http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html > man page). RFC 5452 is about requirements for a resolver (defined in > section 2.1) and -- at least in our interpretation -- specifically > does not set any requirements for a stub resolver. I asked Bert to be sure, and he says that it was his intent that the advice applied to non-recursive resolvers as well. (Note that systemd-resolved is more than a minimal stub because it has a cache.) > Is your message attempting to assert that EVERY implementation of a > stub resolver must satisfy RFC 5452 requirements, in order to account > for the possibility that the configured recursive name servers have > security problems, and the possibility that an attacker can > communicate directly with the stub resolver? The DNS specification does not require rewriting of upstream responses to filter out parts for which the queried server is not authoritative. This means that a downstream caching resolver will tend to poison its cache if it adds data from such responses that are not directly in response to the QNAME. I believe this is still a real-world issue (in the sense that this is triggered accidentally, not through attacks). -- Florian Weimer / Red Hat Product Security
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ