|Summary:||CVE-2016-1548 ntp: ntpd switching to interleaved mode with spoofed packets|
|Product:||[Other] Security Response||Reporter:||Martin Prpič <mprpic>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||anemec, apmukher, jaeshin, mdshaikh, mlichvar, sardella, slawomir|
|Fixed In Version:||ntp 4.2.8p7||Doc Type:||Bug Fix|
It was found that an ntpd client could be forced to change from basic client/server mode to the interleaved symmetric mode. A remote attacker could use a spoofed packet that, when processed by an ntpd client, would cause that client to reject all future legitimate server responses, effectively disabling time synchronization on that client.
|Last Closed:||2016-05-31 08:23:33 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1332160, 1332478, 1332479, 1332480, 1332481, 1356968|
Description Martin Prpič 2016-04-28 14:51:13 UTC
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/
Comment 1 Martin Prpič 2016-04-28 14:51:22 UTC
Acknowledgments: Name: Miroslav Lichvar (Red Hat)
Comment 2 Martin Prpič 2016-05-02 11:37:32 UTC
Created ntp tracking bugs for this issue: Affects: fedora-all [bug 1332160]
Comment 5 Fedora Update System 2016-05-07 11:42:06 UTC
ntp-4.2.6p5-40.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2016-05-10 17:58:33 UTC
ntp-4.2.6p5-40.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2016-05-12 07:21:40 UTC
ntp-4.2.6p5-40.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 8 errata-xmlrpc 2016-05-31 08:12:50 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2016:1141 https://access.redhat.com/errata/RHSA-2016:1141