[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Nov 2014 12:33:08 -0500 (EST)
From: cve-assign@...re.org
To: krahmer@...e.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE-request: systemd-resolved DNS cache poisoning
-----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.
Documentation for some other stub resolvers makes explicit statements
about security expectations, e.g.,
http://www.gnu.org/software/adns/
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=INSTALL
adns is a `stub resolver' ... no defence against bad nameservers or
fake packets which appear to come from your real nameservers. You MUST
use a firewall or other means to block packets which appear to come
from these nameservers, but which were actually sent by other,
untrusted, entities.
See also CVE-2008-4100. The systemd-resolved documentation is
apparently less explicit.
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? Or does your message mean
that there's something unusual about the environments in which
systemd-resolved is deployed, such that one or more RFC 5452
requirements become applicable?
We're not aware of any standard reference that describes required
security properties of a stub resolver. There isn't much in RFC 1123
6.1.3.1(B). RFC 4033 mentions the concept of a security-oblivious stub
resolver, suggesting that this is acceptable.
Is RFC 5452 section 3 item 3 "The response comes from the same network
address to which the question was sent" the single implied requirement
of a stub resolver? In other words, a minimally acceptable stub
resolver can blindly trust its configured recursive name servers by IP
address, but still must discard responses (or document mandatory
firewalling to discard responses) from any other source IP addresses?
Note that this question is only about a requirement, not about what
types of security hardening would be ideally present.
It's conceivable that upstream may decide to announce that one or more
behaviors were vulnerabilities. CVE assignments may be possible then.
This especially applies to the case of implementation errors. We don't
currently see a way to do any CVE assignments until after an
announcement from upstream. We typically would not have an overarching
CVE such as "does not follow RFC 5452 recommendations" even if the
product were advertised as a full-service resolver.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUY5kdAAoJEKllVAevmvmsWOUH/3GcpvpJ1vHFoiwqYzNGj1O6
fYJWbv9hvaDvgpQLBB+Nertc3i5p/uTGXQqBZWUZ5EdZsjUM6Dj0DdIYWAGK59bQ
Xut25F3/xL3JPxlshQW4gY3Yc3FIVw+w3C6+dWZqFAQZ/kFB/IMhBSpb3t0OIXZk
3zW1gT6HtnhZ368NaXnNN3Bdtc/Hnf4RAVnzYjf8BnyqHuMQPGH7OnxzR2eId1Bi
Y2EYSvtdvDU5CDkx+ataME1spuJMLOjMHjeeFUe+VNuiqa6/DIcmhXMFgM8CnYb3
kttu7Xqydf6pi9hGDsbrVIUJiNiChyoxTeE1I3Grp+sd3CiDGhlosZ5DVpLBDS4=
=o1Tu
-----END PGP SIGNATURE-----
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.
