Summary: | <net-misc/ntp-4.2.6_p5-r10 : DoS in monlist feature in ntpd (CVE-2013-5211) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | base-system, chris.kerr, guido-genbugs, whissi |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugs.ntp.org/show_bug.cgi?id=1532 | ||
See Also: |
http://bugs.ntp.org/show_bug.cgi?id=1532 https://bugzilla.redhat.com/show_bug.cgi?id=1047854 https://bugs.gentoo.org/show_bug.cgi?id=515494 |
||
Whiteboard: | B3 [glsa cleanup] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2014-01-02 14:48:24 UTC
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). 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. *** |