** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Robin Park and Dmitri Vinokurov of Alcatel-Lucent reported a Denial of Service vulnerability in ntp before 4.2.4p8 (to be released). Quoting CERT: NTP mode 7 (MODE_PRIVATE) is used by the ntpdc query and control utility. In contrast, ntpq uses NTP mode 6 (MODE_CONTROL), while routine NTP time transfers use modes 1 through 5. Upon receipt of an incorrect mode 7 request or a mode 7 error response from an address which is not listed in a "restrict ... noquery" or "restrict ... ignore" statement, ntpd will reply with a mode 7 error response (and log a message). In this case: o If an attacker spoofs the source address of ntpd host A in a mode 7 response packet sent to ntpd host B, both A and B will continuously send each other error responses, for as long as those packets get through. o If an attacker spoofs an address of ntpd host A in a mode 7 response packet sent to ntpd host A, A will respond to itself endlessly, consuming CPU and logging excessively.
Created attachment 208517 [details, diff] ntp-4.2.4_p7-CVE-2009-3563.patch
Created attachment 208519 [details] ntp-4.2.4_p7-r1.ebuild
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug. Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" CC'ing current Liaisons: alpha : armin76, klausman amd64 : keytoaster, chainsaw hppa : jer ppc : josejx, ranger ppc64 : josejx, ranger sparc : fmccor x86 : fauli, maekke
HPPA is OK.
Correcting liaisons.
x86 ok
sparc ok
ppc/ppc64 are okay.
amd64 is fine. this bug is public now. someone from security will unrestrict the bug as I am just too tired for that now ;)
*** Bug 296350 has been marked as a duplicate of this bug. ***
Public via $URL. base-system: please commit ebuild to the tree with stable keywords as follows: "amd64 hppa ppc ppc64 sparc x86" alpha, arm, ia64, s390, and sh: Please stabilize when bumped.
CVE-2009-3563 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-3563): ntp_request.c in ntpd in NTP before 4.2.4p8, and 4.2.5, allows remote attackers to cause a denial of service (CPU and bandwidth consumption) by using MODE_PRIVATE to send a spoofed (1) request or (2) response packet that triggers a continuous exchange of MODE_PRIVATE error responses between two NTP daemons.
Bumped.
GLSA request filed.
alpha/arm/ia64/s390/sh stable
GLSA 201001-01
Yesterday on my network, the DDoS condition had occurred. Performed the recommended upgrade. Stopped ntpd on both sides of the connection, and then started them back up. The DDoS started again almost immediately. 100% CPU utilization on the client, 50% CPU utilization on the server. 3.5 MB/s of constant NTP traffic between the hosts. If possible, I would like this bug reopened.
I'm wondering how that could happen. Do you have pcap dump you can send?
http://www.hamiltonshells.ca/~chris/storage/other/dump-2010-01-26-18:11:40.log http://www.hamiltonshells.ca/~chris/storage/other/dump-2010-01-26-19:10:37.log I capped these last night while I was in #ntp. ~20MB each, they run for about 5 seconds. A lot of packets here.
I just noticed that craig@g.o. is now on away until the summer. Can I please have someone check this stuff for me? I'd like my CPU time and bandwidth back. And if you don't believe that I'm using the right version... http://www.hamiltonshells.ca/~chris/storage/other/shell-ntp.txt http://www.hamiltonshells.ca/~chris/storage/other/poweredge-ntp.txt http://www.hamiltonshells.ca/~chris/images/screenshots/busted-ntp.png
FYI: I'm not away till summer, just one more week (depending on circumstances +1 month maybe). ;)
I find it rather hard to believe that only one person can help me with this issue. CVE to GLSA took less than 24 hours, but I've been waiting for over 2 weeks to get help regarding the same issue. If I have to wait another month to get some assistance, I'll seriously be considering Debian or BSD when I buy and upgrade my current network to a hardened architecture.
a) Your problem seems be some other network glitch as this was patched already. I'm not very keen to analyse your network problems in my free time. To your very great suprise, others members from the security team will most likely feel the same way. b) If you want fixed timeframes in which your problems are solved, I suggest you buy a distro with professional support (RHEL or SLES) and do not run a distribution that is run by volunteers in their free time. c) You're free to become a developer yourself or to get out strace & gdb. If you're not able to do that, you might consider calling a consultant that can fix your problems. d) Don't forget that you neither payed anything, nor did gentoo promise you anything; you cannot scare anyone by saying you will use Debian or BSD. Why should anyone care at all? It will rather make everyone laugh. e) I will not touch this bug for one month from now on, so that you have enough time to think about b) (or analyse your problems yourself). Writing this has already been a waste of time, I will not take part in any further discussion about the whole issue and am not available until 07th march.
