From ${URL} : Common Vulnerabilities and Exposures assigned an identifier CVE-2013-5211 to the following vulnerability: Name: CVE-2013-5211 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5211 Assigned: 20130815 Reference: http://openwall.com/lists/oss-security/2013/12/30/6 Reference: http://openwall.com/lists/oss-security/2013/12/30/7 Reference: http://lists.ntp.org/pipermail/pool/2011-December/005616.html Reference: http://bugs.ntp.org/show_bug.cgi?id=1532 Reference: http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p26.tar.gz The monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1 requests, as exploited in the wild in December 2013. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
going by the upstream ntp bug, there's really nothing feasible for us to do at this time. i don't think we want to add+stabilize the 4.2.7 dev branch (we've never carried the 4.2.7 dev series by design), and backporting is not feasible (according to the ntp developers themselves).
I solved this in the tree already actually, before you filed this bug; with a solution accepted by upstream: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/ntp/files/ntp.conf?r1=1.19&r2=1.20 For that, please stablereq for ntp-4.2.6_p5-r10
Thanks. Arches, please test and mark stable: =net-misc/ntp-4.2.6_p5-r10 Target KEYWORDS: "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
amd64 stable
(In reply to Robin Johnson from comment #2) that doesn't fix the bug, just makes it not show up if you use the default config. but maybe that's good enough for us until upstream releases a proper version.
Well, there never will be a fix (because there isn't a bug and they cannot change the behavior without breaking clients). They just decided to remove the 'monlist' feature in favor of the new safe 'mrunlist' function, which uses a nonce value ensuring that received IP address match the actual requester. But this is 4.2.7 which isn't in tree and marked as development branch by upstream (not sure if they are going to release a stable 4.2.7 in a few days because of this problem). With Robin's configuration change ("noquery" was added to the default restrictions) we disable mode 6 and 7 queries, which includes monlist. What I don't like about the Gentoo "fix" (if it is meant as a fix and a GLSA will tell the user "upgrade to =ntp-4.2.6_p5-r10 and you aren't longer vulnerable to CVE-2013-5211") is that people running their own configuration and don't know about the problem may not recognize the added "noquery" option and why it is important that they adapt it.
Stable for HPPA.
ppc stable
ppc64 stable
sparc stable
whissi: to solve your concern, I think we can have the GLSA contain some text like: ==== If you use a non-default configuration for ntpd, you should add the "noquery" argument to your "restrict default" configuration entries and any other entries for untrusted networks. ====
CVE-2013-5211 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5211): The monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1 requests, as exploited in the wild in December 2013.
x86 stable
arm stable
alpha stable
(In reply to Robin Johnson from comment #11) > whissi: > to solve your concern, I think we can have the GLSA contain some text like: > ==== > If you use a non-default configuration for ntpd, you should add the > "noquery" argument to your "restrict default" configuration entries and any > other entries for untrusted networks. > ==== Something like that, but I don't like the text. We agree that a real fix is missing (will be the not yet existing 4.2.8 release). So we don't have a "resolution", we only have a "workaround". The GLSA provides both information, let us use them: Workaround: =========== We modified the default ntp configuration in "=net-misc/ntp-4.2.6_p5-r10" and added "noquery" to the default restriction which disallows anyone to query your ntpd status, including "monlist". If you use a non-default configuration and provide a public ntp service we highly recommend you to revise your configuration to disable mode 6 and 7 queries for any untrusted (public) network. You can always enable these queries for specific trusted networks. For more details please see the "Access Control Support" chapter in the ntp.conf(5) man page. Resolution: =========== All NTP users should upgrade to the latest version which includes an updated configuration which disables ntpd status queries per default: ... Steps how to update ... What do you think? This will include the information: - that there is no upstream fix for this problem yet - how we solved the problem - what the user should check for if running a non-default configuration - where to find further information
(In reply to Thomas D. from comment #16) > If you use a non-default configuration and provide a public ntp service we > highly recommend you to revise your configuration to disable mode 6 and 7 > queries for any untrusted (public) network. I'm concerned that most people with custom configs will see 'public ntp service' and ignore the rest of the paragraph. Untrusted networks aren't necessarily public networks. Maybe reword as: If you use a non-default configuration, and provide a ntp service to untrusted networks, we highly recommend you to revise your configuration to disable mode 6 and 7 queries for any untrusted (public) network.
Good point. I like your rewording. No further objections from me.
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
GLSA vote: yes
YES too, request filed.
This issue was resolved and addressed in GLSA 201401-08 at http://security.gentoo.org/glsa/glsa-201401-08.xml by GLSA coordinator Tobias Heinlein (keytoaster).
*** Bug 498706 has been marked as a duplicate of this bug. ***
*** Bug 506710 has been marked as a duplicate of this bug. ***