TALOS-2016-0081
Network Time Protocol Crypto-NAK Preemptable Association Denial of Service Vulnerability
April 26, 2016
Report ID
CVE-2016-1547
Summary
An off-path attacker can cause a preemptable client association to be demobilized by sending a crypto NAK packet to a victim client with a spoofed source address of an existing associated peer. This is true even if authentication is enabled.
Furthermore, if the attacker keeps sending crypto NAK packets, for example every one second, the victim never has a chance to reestablish the association and synchronize time with the legitimate server.
Tested Versions
ntp 4.2.8p3
ntp 4.2.8p4
NTPSec a5fb34b9cc89b92a8fef2f459004865c93bb7f92
Product URLs
http://www.ntp.org
http://www.ntpsec.org/
CVSSv3 Score
CVSSv2: 4.3 - AV:N/AC:M/Au:N/C:N/I:N/A:P
CVSSv3: 3.7 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Details
The root cause of this defect is an error in ntp_proto.c that causes an association to be demobilized with a call to the unpeer() function when a crypto-NAK packet is received and FLAG_PREEMPT is set for the peer.
The defect occurs when an unauthenticated crypto-NAK packet with the source address of an existing peer with whom the client has a preemptable association reaches the following code:
1292 /*
1293 * If this is a crypto_NAK, the server cannot authenticate a
1294 * client packet. The server might have just changed keys. Clear
1295 * the association and restart the protocol.
1296 */
1297 if (is_authentic == AUTH_CRYPTO) {
1298 report_event(PEVNT_AUTH, peer, "crypto_NAK");
1299 peer->flash |= TEST5; /* bad auth */
1300 peer->badauth++;
1301 if (peer->flags & FLAG_PREEMPT) {
1302 unpeer(peer);
1303 return;
1304 }
...
1319 }
Since the packet is a crypto-NAK, and the client has a preemptable association with the peer, is_authentic == AUTH_CRYPTO will be true, the FLAG_PREEMPT bit will be set in peer->flags, and the call to unpeer() will occur.
The documentation states that preemptable associations are created when the preempt flag is specified with the server command in the ntp configuration or upon arrival of an automatic server discovery packet.
Examination of the code reveals that preemptable associations are created in the following ways:
1. Configuration:
A preempt flag is parsed in the the ntp configuration file will cause peerflags to have the FLAG_PREEMPT flag set.
ntp_config.c:
3686 case T_Preempt:
3687 peerflags |= FLAG_PREEMPT;
3688 break;
2. Broadcast, Multicast:
There are two places where broadcast and multicast associations can be created.
The first packet from either a broadcast server or multicast server is received, the client is configured as a broadcast or multicast client, and sys_bdelay != 0.
One example of when this will occur is when a broadcast delay is specified in the configuration.
ntp_proto.c:
985 case AM_NEWBCL:
...
1045 if (sys_bdelay != 0) {
...
1061 peer = newpeer(&rbufp->recv_srcadr, NULL,
1062 match_ep, MODE_BCLIENT, hisversion,
1063 pkt->ppoll, pkt->ppoll, FLAG_PREEMPT,
1064 MDF_BCLNT, 0, skeyid, sys_ident);
...
1072 break;
1073 }
The second case occurs when the first packet from a broadcast or multicast server is received, the client is a broadcast or multicast client, and sys_bdelay == 0.
ntp_proto.c:
985 case AM_NEWBCL:
...
1083 peer = newpeer(&rbufp->recv_srcadr, NULL, match_ep,
1084 MODE_CLIENT, hisversion, pkt->ppoll, pkt->ppoll,
1085 FLAG_BC_VOL | FLAG_IBURST | FLAG_PREEMPT, MDF_BCLNT,
1086 0, skeyid, sys_ident);
3. Manycast, Pool:
A manycast server mode packet is received in response to a client mode packet sent to a multicast group address for manycastclient or a unicast address for pool.
ntp_proto.c:
921 case AM_MANYCAST:
...
952 peer = newpeer(&rbufp->recv_srcadr, NULL, rbufp->dstadr,
953 MODE_CLIENT, hisversion, peer2->minpoll,
954 peer2->maxpoll, FLAG_PREEMPT |
955 (FLAG_IBURST & peer2->flags), MDF_UCAST |
956 MDF_UCLNT, 0, skeyid, sys_ident);
In our virtualized testbed, we were able to cause demobilization of preemptable associations and denial of service in each of these cases.
Mitigation
The underlying causes of this defect are similar to those of other recent defects reported by Cisco and Boston University. Specifically, they are similar to those of the the NAK-to-the-Future defect discovered by Matthew Van Gundy and the off-path authenticated broadcast mode denial of service discovered by Aanchal Malhotra.
The recommendations are likewise similar:
Packets that fail to authenticate in authenticated modes should be discarded prior to being allowed to change the state of NTP.
Because crypto-NAKs are not authenticated, changing state upon receipt of a crypto-NAK may introduce vulnerabilities which affect integrity and availability.
RFC 5905 does not specify any required actions for clients to take upon receipt of a crypto-NAK packet. As a result, it may be safe for clients to ignore crypto-NAK packets entirely.
Even in unauthenticated modes, more sanity checks, such as origin timestamp validation, should take place to ensure that the packet being received is likely legitimate.
Credit
This defect was discovered by Stephen Gray and Matthew Van Gundy of Cisco ASIG.
Timeline
2016-01-19 - CERT reports to NTP