[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Nov 2014 09:42:13 +0100
From: Sebastian Krahmer <krahmer@...e.de>
To: Daniel Kahn Gillmor <dkg@...thhorseman.net>
Cc: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-request: systemd-resolved DNS cache
poisoning
On Thu, Nov 13, 2014 at 08:03:36AM -1000, Daniel Kahn Gillmor wrote:
> On 11/13/2014 04:56 AM, Florian Weimer wrote:
> >
> > 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.)
>
> I have to agree with Florian here.
>
> It's possible that rfc5452 was the wrong citation, since it seems to be
> devoted mainly to making sure that you don't accept packets from remote
> DNS servers you didn't request them from.
I named rfc5452 since it pretty much enumerates best DNS security
practises of the last 20 years. systemd never states to implement
rfc5452 and so everyone can sleep well and hide behind the word 'stub'.
But in fact systemd's aim is to replace core system components like
the system-resolver. What other reason could exist, that the proper nsswitch
modules are provided as well or that the project itself exists at all?
So replacing core DNS components of Linux in mass setups shows
up on the horizon; at least it is attempted. Thats enough reason for
us to look at the code.
Even when I agree that DNSSEC should be used to address all the
shortcomings, its not acceptable to throw away last 20 years of DNS security
evolution en passant.
>
> the problem with systemd-resolved as i understand it not that it's
> accepting packets from DNS servers it didn't request from, but that it's
> caching unrelated responses in those records.
Exactly. Now one can argue that an upstream DNS will filter such (well formed)
garbage. But how many desktop users set up their own filtering bind9 on
127.0.0.1 or on a dedicated host (properly shielded by ingress filtering,
otherwise its useless)? I bet _a lot_ will just use 8.8.8.8 or its v6 alternative,
also because systemd-resolved comes with these DNS servers pre-configured (!).
How easy do we want to make it to the agency to twist the MX records
on SMTP servers??
I'd be happy with no CVE being assigned. At the end I just want to
have the cache hardened.
Sebastian
--
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security Team
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.
