An off-path attacker can cause a preemptible 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.
ntp 4.2.8p3 ntp 4.2.8p4 NTPSec a5fb34b9cc89b92a8fef2f459004865c93bb7f92
http://www.ntp.org http://www.ntpsec.org/
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 preemptible 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 preemptible association with the peer, isauthentic == AUTHCRYPTO will be true, the FLAG_PREEMPT bit will be set in peer->flags, and the call to unpeer() will occur.
The documentation states that preemptible 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 preemptible associations are created in the following ways:
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);
ntpproto.c: 921 case AMMANYCAST: ... 952 peer = newpeer(&rbufp->recvsrcadr, NULL, rbufp->dstadr, 953 MODECLIENT, hisversion, peer2->minpoll, 954 peer2->maxpoll, FLAGPREEMPT | 955 (FLAGIBURST & peer2->flags), MDFUCAST | 956 MDFUCLNT, 0, skeyid, sys_ident);
In our virtualized testbed, we were able to cause demobilization of preemptible associations and denial of service in each of these cases.
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: