Talos Vulnerability Report

SUMMARY

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.

TESTED VERSIONS

ntp 4.2.8p3 ntp 4.2.8p4 NTPSec a5fb34b9cc89b92a8fef2f459004865c93bb7f92

PRODUCT URLs

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

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 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, 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 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:

1. CONFIGURATION: A preempt flag is parsed in the the NTP configuration file will cause peer flags 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);

1. 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 preemptible 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:

1. 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.

2. 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.

TIMELINE

2016-01-19 - CERT reports to NTP
2016-04-26 - Public disclosure