Robin Park and Dmitri Vinokurov of Alcatel-Lucent discovered a flaw in the way ntpd handles certain mode 7 packets. A remote attacker able to send specially-crafted mode 7 NTP packet with a spoofed source IP address could cause ntpd running on one host, or two ntpds running on two hosts to send error packets in loop, resulting in excessive use of CPU and disk space (via logging). Issue is tracked by US-CERT as VU#568372.
Created attachment 366233 [details] Upstream patch to be included in 4.2.4p8
Impact and mitigations: - mode 7 NTP packets are processed by ntpd when they have source IP which is allowed to query - when malformed mode 7 packet is received, ntpd sends back a reply packet (using mode 7 again), this reply packet, when received by other ntpd, triggers similar reply (resulting in reply loop among the two ntp hosts) - ntpd implements a check that prevents it from replying to packets with source IP:port matching any of the local network interfaces on which ntpd listens; this mitigates single host reply loops, but they may still be possible to trigger using loopback addresses - excessive disk usage is mitigated by the way syslogd reports duplicate messages (message is recorded once and repeat count is recorded when the next different message is received); this mitigation may be minimized during the multiple parallel attacks - single host reply loops using loopback addresses can be blocked by dropping all packets with source addresses 127/8 not received via loopback interface (via netfilter rule or rp_filter settings) - mode 7 packets are normally generated by ntpdc - ntpd query and configuration command. packets from ntpdc normally do not have source port 123, so mode 7 NTP packets with source port 123 should be considered suspicious. - netfilter module u32 can match mode 7 NTP packets using a check as: --u32 "0>>22&0x3C@8>>24&0x7=7" u32 module is, however, not included in kernel packages for current Red Hat Enterprise Linux versions note: this check needs to be combined with other check (udp packet, source / destination port 123) - it's possible to mitigate this attack using recent netfilter module by limiting maximum amount of NTP packets allowed to be received from single IP address during the specified time period (break reply loops)
This is public now: https://lists.ntp.org/pipermail/announce/2009-December/000086.html and: https://support.ntp.org/bugs/show_bug.cgi?id=1331
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2009:1648 https://rhn.redhat.com/errata/RHSA-2009-1648.html
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Via RHSA-2009:1651 https://rhn.redhat.com/errata/RHSA-2009-1651.html
ntp-4.2.4p8-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ntp-4.2.4p8-1.fc12
ntp-4.2.4p7-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ntp-4.2.4p7-3.fc11
ntp-4.2.4p7-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/ntp-4.2.4p7-2.fc10
ntp-4.2.4p8-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ntp-4.2.4p7-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
ntp-4.2.4p7-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.