Talos Vulnerability Report

CERT VU#357792

Summary

To prevent off-path attackers from impersonating legitimate peers, clients require that the origin timestamp in a received response packet match the transmit timestamp from its last request to a given peer. Under assumption that only the recipient of the request packet will know the value of the transmit timestamp, this prevents an attacker from forging replies.

Unfortunately, ntpq and ntpdc will disclose the value of the origin timestamp expected in the next peer response to any clients that are authorized to make ntpq (respectively ntpdc) queries.

This vulnerability appears to have been present in ntpd since, at least, 4.0.94 of May 1999. It appears in the earliest commit in the NTP project git repository.

Tested Versions

ntp 4.2.8p3
NTPsec a5fb34b9cc89b92a8fef2f459004865c93bb7f92

Product URLs

http://www.ntp.org
http://www.ntpsec.org/

CVSS Score

CVSSv2: 5.0 - AV:N/AC:L/Au:N/C:P/I:N/A:N
CVSSv3: 5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Details

Here is an example from ntpq:

ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server          .LOCL.           1 u   69   64   76    0.525   35.063  23.483
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 43286  965a   yes   yes  none  sys.peer    sys_peer  5
ntpq> rv 43286 org
org=d9c79a63.b05e631b  Tue, Oct 13 2015 14:57:39.688

Here is an example from ntpdc:

ntpdc> showpeer 192.168.33.10
remote 192.168.33.10, local 192.168.33.11
...
reference time:      d9c79a0e.1ef70a98  Tue, Oct 13 2015 14:56:14.120
originate timestamp: d9c79a63.b05e631b  Tue, Oct 13 2015 14:57:39.688
receive timestamp:   d9c79a20.b9d5ee3d  Tue, Oct 13 2015 14:56:32.725
transmit timestamp:  d9c79a20.b9d5ee3d  Tue, Oct 13 2015 14:56:32.725

For associations that do not employ authentication, response packets are only authenticated using the packet source address and the expected origin timestamp. The necessary ntpq and ntpdc commands do not require authentication. As a result, an unauthenticated off-path attacker that can spoof the source address of a remote peer can forge responses from that peer using this vulnerability.

There is an interplay between this vulnerability and the 0rigin (zero origin) vulnerability (CVE-2015-8138). Because the 0rigin vulnerability resets the expected origin timestamp from live servers to zero when a response with the correct origin timestamp is received, forging responses from live servers is trivial. This vulnerability gives attackers the additional power to forge responses from unreachable peers and symmetric peers.

Mitigation

The peer origin variable is read via ntpq (mode 6) packets with a non-zero association id, opcode equal to READVAR (2), and the variable name “org”.

It can also be read with ntpdc (mode 7) packets with a request code of PEER_INFO (2).

This vulnerability can be mitigated by adding the noquery option to all restrict entries as in:

restrict -4 default noquery ...
restrict -6 default noquery ...
restrict 127.0.0.1 noquery ...
restrict ::1 noquery ...

WARNING: Common configurations allow local users to send ntpq and ntpdc requests to the local ntpd using permissive restrict entries. This will allow malicious, unprivileged, local users to discover the value of the origin timestamp necessary to spoof responses from ntpd peers. Therefore, we DO NOT recommend the common practice of allowing queries from localhost.

Unfortunately, despite the impression given by NTP’s documentation, the notrust restrict option CANNOT be used to mitigate this vulnerability because it DOES NOT have any effect on ntpq and ntpdc requests.

Timeline

2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release