Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.