Bug 1331462 (CVE-2016-1548)

ntpd supports an interleaved mode to allow the protocol to exchange transmit timestamps that were captured after the packet was sent in symmetric associations and broadcast modes. It can be enabled in the configuration file, but it's also enabled automatically when a packet received from the source is detected to be in the interleaved mode. The detection compares the origin timestamp in the packet to the previous local receive timestamp. The interleaved mode is enabled even in client associations, even though it makes no sense there.

The problem is that the reference timestamp, which is revealed in all packets, is set to the local receive timestamp when the clock is updated. An off-path attacker can use ordinary client packets to monitor the server's reference timestamp and reference ID, wait for a clock update, and send the server a spoofed packet that will switch the association to the interleaved mode. This effectively disables the synchronization with the source as packets received from that point will not pass the checks used in the interleaved mode. The attack can be repeated for other sources when ntpd reselects. Unless the sources can be replaced (as with the pool directive for instance), the client will stay unsynchronized.

Upstream bugs:

http://support.ntp.org/bin/view/Main/NtpBug2978

External References:

http://support.ntp.org/bin/view/Main/SecurityNotice#April_2016_NTP_4_2_8p7_Security
http://www.talosintel.com/reports/TALOS-2016-0082/