Talos Vulnerability Report
Network Time Protocol ntpq and ntpdc Origin Timestamp Disclosure Vulnerability
January 19, 2016
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.
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
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.
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,
notrust restrict option CANNOT be used to mitigate this
vulnerability because it DOES NOT have any effect on ntpq and ntpdc
This defect was discovered by Matthew Van Gundy of Cisco ASIG.
2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release