Vulnerabilities > CVE-2015-7973 - 7PK - Security Features vulnerability in multiple products

047910
CVSS 5.8 - MEDIUM
Attack vector
NETWORK
Attack complexity
MEDIUM
Privileges required
NONE
Confidentiality impact
NONE
Integrity impact
PARTIAL
Availability impact
PARTIAL
network
ntp
siemens
freebsd
netapp
canonical
CWE-254
nessus
NVD
Published: 2017-01-30
Updated: 2021-04-26

Summary

NTP before 4.2.8p6 and 4.3.x before 4.3.90, when configured in broadcast mode, allows man-in-the-middle attackers to conduct replay attacks by sniffing the network.

Vulnerable Configurations

Part Description Count
Application
Ntp
800
Application
Netapp
2
OS
Siemens
2
OS
Freebsd
68
OS
Canonical
3
Hardware
Siemens
2

Common Weakness Enumeration (CWE)

Nessus

Seebug

  • bulletinFamilyexploit
    description### Summary An exploitable denial of service vulnerability exists in the broadcast mode replay prevention functionality of ntpd. To prevent replay of broadcast mode packets, ntpd rejects broadcast mode packets with non-monotonically increasing transmit timestamps. Remote unauthenticated attackers can send specially crafted broadcast mode NTP packets to cause ntpd to reject all broadcast mode packets from legitimate NTP broadcast servers. ### Tested Versions NTP 4.2.8p6 ### Product URLs http://www.ntp.org/ ### CVSS Scores CVSSv2: 5.0 - (AV:N/AC:L/Au:N/C:N/I:N/A:P) CVSSv3: 5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L ### Details In response to the NTP Deja Vu vulnerability (CVE-2015-7973), ntp-4.2.8p6 introduced several new integrity checks on incoming broadcast mode packets. Upon receipt of a broadcast mode packet, before authentication is enforced, ntpd will reject the packet if any of the following conditions hold: 1. The packet poll value is out of bounds for the broadcast association, i.e. ``` pkt->ppoll < peer->minpoll || pkt->ppoll > peer->maxpoll ``` 2. The packet was received before a full poll interval has elapsed since the last broadcast packet was received from the packet's sender. i.e. A server cannot ingress packets more frequently than `peer->minpoll`. 3. The packet transmit timestamp is less than the last seen broadcast packet transmit timestamp from the packet's sender. i.e. Broadcast packet transmit timestamps must be monotonically increasing. The following logic is used to ensure that packet transmit timestamps are monotonically increasing: ``` /* ntp-4.2.8p6 ntpd/ntp_proto.c */ 1305 if (MODE_BROADCAST == hismode) { ... 1351 tdiff = p_xmt; 1352 L_SUB(&tdiff, &peer->bxmt); 1353 if (tdiff.l_i < 0) { 1354 msyslog(LOG_INFO, "receive: broadcast packet from %s contains non-monotonic timestamp: %#010x.%08x -> %#010x.%08x", 1355 stoa(&rbufp->recv_srcadr), 1356 peer->bxmt.l_ui, peer->bxmt.l_uf, 1357 p_xmt.l_ui, p_xmt.l_uf 1358 ); 1359 ++bail; 1360 } 1361 1362 peer->bxmt = p_xmt; 1363 1364 if (bail) { 1365 peer->timelastrec = current_time; 1366 sys_declined++; 1367 return; 1368 } 1369 } ``` If the packet transmit timestamp is less than the transmit timestamp on the last received broadcast packet from this association (`p_xmt - peer->bxmt < 0`), the packet will be discarded. Unfortunately, line 1362 updates the saved transmit timestamp for alleged sender of the packet (`peer->bxmt`) before the packet is discarded. The update takes place even if the packet is unauthenticated and fails the previous integrity checks. This leads to a trivial denial of service attack. The attacker: 1. Discovers the IP address of the victim's broadcast server. e.g. Send the victim a client mode NTP packet and discover the broadcast server from the refid field of the victim's reply. 2. Every poll period, send the victim a spoofed broadcast mode packet from the broadcast server with a transmit timestamp in the future. This will move `peer->bxmt` forward so that any legitimate packet will be rejected by the non-monotonic timestamp check. * The attacker does not need to be on the same subnet as the victim. The attacker can address the spoofed broadcast NTP packet directly to the victim's IP address. * The attacker can choose any reasonably small estimate for the poll period. Because the `peer->bxmt` update happens even when a packet fails the poll period checks, there is no penalty for sending packets too frequently. To prevent this vulnerability, `peer->bxmt` should only be updated when a packet authenticates correctly. This is the approach taken in the patch below. ### Mitigation There is no workaround for this issue. Because the vulnerable logic is executed before authentication is enforced, authentication and the `restrict notrust` ntpd.conf directive have no effect. An attacker can bypass `notrust` restrictions by sending incorrectly authenticated packets. In order to succeed in an attack, the attacker must send at least one spoofed packet per poll period. Therefore observing more than one NTP broadcast packet from the same sender address per poll period indicates a possible attack. The following patch can be used to fix this vulnerability: ``` From 097fd4dae9ac4927d7cfa8011fd42f704bd02c45 Mon Sep 17 00:00:00 2001 From: Matthew Van Gundy <[email protected]> Date: Tue, 26 Jan 2016 15:00:28 -0500 Subject: [PATCH] Fix unauthenticated broadcast mode denial of service (peer->bxmt) --- include/ntp_fp.h | 1 + ntpd/ntp_proto.c | 22 ++++++++++++++++------ 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/include/ntp_fp.h b/include/ntp_fp.h index 7806932..ad7a01d 100644 --- a/include/ntp_fp.h +++ b/include/ntp_fp.h @@ -242,6 +242,7 @@ typedef u_int32 u_fp; #define L_ISGTU(a, b) M_ISGTU((a)->l_ui, (a)->l_uf, (b)->l_ui, (b)->l_uf) #define L_ISHIS(a, b) M_ISHIS((a)->l_ui, (a)->l_uf, (b)->l_ui, (b)->l_uf) #define L_ISGEQ(a, b) M_ISGEQ((a)->l_ui, (a)->l_uf, (b)->l_ui, (b)->l_uf) +#define L_ISGEQU(a, b) L_ISHIS(a, b) #define L_ISEQU(a, b) M_ISEQU((a)->l_ui, (a)->l_uf, (b)->l_ui, (b)->l_uf) /* diff --git a/ntpd/ntp_proto.c b/ntpd/ntp_proto.c index ad45409..ac469ce 100644 --- a/ntpd/ntp_proto.c +++ b/ntpd/ntp_proto.c @@ -1305,7 +1305,6 @@ receive( if (MODE_BROADCAST == hismode) { u_char poll; int bail = 0; - l_fp tdiff; DPRINTF(2, ("receive: PROCPKT/BROADCAST: prev pkt %ld seconds ago, ppoll: %d, %d secs\n", (current_time - peer->timelastrec), @@ -1348,9 +1347,8 @@ receive( ++bail; } - tdiff = p_xmt; - L_SUB(&tdiff, &peer->bxmt); - if (tdiff.l_i < 0) { + /* Use L_ISGEQU() to ensure unsigned comparison */ + if (!L_ISGEQU(&p_xmt, &peer->bxmt)) { msyslog(LOG_INFO, "receive: broadcast packet from %s contains non-monotonic timestamp: %#010x.%08x -> %#010x.%08x", stoa(&rbufp->recv_srcadr), peer->bxmt.l_ui, peer->bxmt.l_uf, @@ -1359,8 +1357,6 @@ receive( ++bail; } - peer->bxmt = p_xmt; - if (bail) { peer->timelastrec = current_time; sys_declined++; @@ -1563,6 +1559,14 @@ receive( peer->xmt = p_xmt; /* + * Now that we know the packet is correctly authenticated, + * update peer->bxmt if needed + */ + if (MODE_BROADCAST == hismode) { + peer->bxmt = p_xmt; + } + + /* * Set the peer ppoll to the maximum of the packet ppoll and the * peer minpoll. If a kiss-o'-death, set the peer minpoll to * this maximum and advance the headway to give the sender some @@ -2400,6 +2404,7 @@ peer_clear( ) { u_char u; + l_fp bxmt = peer->bxmt; #ifdef AUTOKEY /* @@ -2436,6 +2441,11 @@ peer_clear( peer->flash = peer_unfit(peer); peer->jitter = LOGTOD(sys_precision); + /* Don't throw away our broadcast replay protection */ + if (peer->hmode == MODE_BCLIENT) { + peer->bxmt = bxmt; + } + /* * If interleave mode, initialize the alternate origin switch. */ ``` ### Timeline * 2016-09-12 - Vendor Disclosure * 2016-11-21 - Public Release
    idSSV:96650
    last seen2017-11-19
    modified2017-10-11
    published2017-10-11
    reporterRoot
    titleNetwork Time Protocol Broadcast Mode Replay Prevention Denial of Service Vulnerability(CVE-2016-7427)
  • bulletinFamilyexploit
    description### Summary An exploitable denial of service vulnerability exists in the broadcast mode poll interval enforcement functionality of ntpd. To limit abuse, ntpd restricts the rate at which each broadcast association will process incoming packets. ntpd will reject broadcast mode packets that arrive before the poll interval specified in the preceding broadcast packet expires. A vulnerability exists which allows remote unauthenticated attackers to send specially crafted broadcast mode NTP packets which will cause ntpd to reject all broadcast mode packets from legitimate NTP broadcast servers. ### Tested Versions NTP 4.2.8p6 ### Product URLs http://www.ntp.org/ ### CVSS Scores * CVSSv2: 5.0 - (AV:N/AC:L/Au:N/C:N/I:N/A:P) * CVSSv3: 5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L ### Details In response to the NTP Deja Vu vulnerability (CVE-2015-7973), ntp-4.2.8p6 introduced several new integrity checks on incoming broadcast mode packets. Upon receipt of a broadcast mode packet, before authentication is enforced, ntpd will reject the packet if any of the following conditions hold: 1. The packet poll value is out of bounds for the broadcast association, i.e. ``` pkt->ppoll < peer->minpoll || pkt->ppoll > peer->maxpoll ``` 2. The packet was received before a full poll interval has elapsed since the last broadcast packet was received from the packet's sender. i.e. A server cannot ingress packets more frequently than `peer->minpoll`. 3. The packet transmit timestamp is less than the last seen broadcast packet transmit timestamp from the packet's sender. i.e. Broadcast packet transmit timestamps must be monotonically increasing. The following logic is used to ensure constraint 2, which ensures that broadcast associations will process only one incoming packet per poll interval: ``` /* ntp-4.2.8p6 ntpd/ntp_proto.c */ 1305 if (MODE_BROADCAST == hismode) { ... 1341 if ( (current_time - peer->timelastrec) 1342 < (1 << pkt->ppoll)) { 1343 msyslog(LOG_INFO, "receive: broadcast packet from %s arrived after %ld, not %d seconds!", 1344 stoa(&rbufp->recv_srcadr), 1345 (current_time - peer->timelastrec), 1346 (1 << pkt->ppoll) 1347 ); 1348 ++bail; 1349 } ... 1361 1362 peer->bxmt = p_xmt; 1363 1364 if (bail) { 1365 peer->timelastrec = current_time; 1366 sys_declined++; 1367 return; 1368 } 1369 } ``` If the time elapsed since the last broadcast packet was received from this peer is less than the poll interval declared by the sender (`(current_time - peer->timelastrec) < (1 << pkt->ppoll)`), the packet will be discarded. (A previous check ensures that `pkt->ppoll` is within acceptable bounds.) Unfortunately, line 1341 compares the current time against the last time any broadcast mode packet was received with a source IP address of the peer (`peer->timelastrec`). In contrast to `peer->timereceived`, which is updated only when a clean (correctly authenticated and passing integrity checks) packet is received, `peer->timelastrec` is updated by all incoming broadcast packets including spoofed and replayed packets. This leads to a trivial denial of service attack. The attacker: 1. Discovers the IP address of the victim's broadcast server. e.g. Send the victim a client mode NTP packet and discover the broadcast server from the refid field of the victim's reply. 2. At least once per poll period, send the victim a spoofed broadcast mode packet from the broadcast server. This will set `peer->timelastrec = current_time` such that, when a legitimate packet is received, it will appear to have been received too early (`(current_time - peer->timelastrec) < (1 << pkt->ppoll)`) and will be discarded. * The attacker does not need to be on the same subnet as the victim. The attacker can address the spoofed broadcast NTP packet directly to the victim's IP address. * The attacker can choose any reasonably small estimate for the poll period. Because the `peer->timelastrec` update happens even when a packet fails the poll period check, there is no penalty for sending packets too frequently. To prevent this vulnerability, ntpd should only discard packets broadcast packets when less than one poll interval has elapsed since the last legitimate packet has been received (`peer->timereceived`). ### Mitigation There is no workaround for this issue. Because the vulnerable logic is executed before authentication is enforced, authentication and the `restrict notrust` ntpd.conf directive have no effect. An attacker can bypass `notrust` restrictions by sending incorrectly authenticated packets. In order to succeed in an attack, the attacker must send at least one spoofed packet per poll period. Therefore observing more than one NTP broadcast packet from the same sender address per poll period indicates a possible attack. The following patch can be used to fix this vulnerability: ``` From 8522882496d3df2bd764de6d8f7afac4a8d84006 Mon Sep 17 00:00:00 2001 From: Matthew Van Gundy <[email protected]> Date: Fri, 5 Feb 2016 17:38:32 -0500 Subject: [PATCH] Fix unauthenticated broadcast mode denial of service (peer->timelastrec) Drop packets if they arrive less than one poll interval since the last **clean** packet received on an association. If we compare against the last time that *any* packet was received, even one that will be dropped for failing integrity checks, an attacker can DoS the association by sending incorrectly authenticated packets or replaying old packets to keep bumping the peer->timelastrec timer forward. --- include/ntp.h | 4 +++- ntpd/ntp_proto.c | 13 +++++++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/include/ntp.h b/include/ntp.h index 6a4e9aa..cbf6cec 100644 --- a/include/ntp.h +++ b/include/ntp.h @@ -383,7 +383,9 @@ struct peer { * Statistic counters */ u_long timereset; /* time stat counters were reset */ - u_long timelastrec; /* last packet received time */ + u_long timelastrec; /* last packet received time (may + * include spoofed, replayed, or other + * invalid packets) */ u_long timereceived; /* last (clean) packet received time */ u_long timereachable; /* last reachable/unreachable time */ diff --git a/ntpd/ntp_proto.c b/ntpd/ntp_proto.c index ad45409..1ea5cee 100644 --- a/ntpd/ntp_proto.c +++ b/ntpd/ntp_proto.c @@ -1338,11 +1338,20 @@ receive( ++bail; } - if ( (current_time - peer->timelastrec) + /* + * Ensure that at least one poll interval has + * elapsed since the last **clean** packet was + * received. We limit the check to **clean** + * packets to prevent replayed packets and + * incorrectly authenticated packets, which + * we'll discard, from being used to create a + * denial of service condition. + */ + if ( (current_time - peer->timereceived) < (1 << pkt->ppoll)) { msyslog(LOG_INFO, "receive: broadcast packet from %s arrived after %ld, not %d seconds!", stoa(&rbufp->recv_srcadr), - (current_time - peer->timelastrec), + (current_time - peer->timereceived), (1 << pkt->ppoll) ); ++bail; -- 2.5.2 ``` ### Timeline * 2016-09-12 - Vendor Disclosure * 2016-11-21 - Public Release
    idSSV:96648
    last seen2017-11-19
    modified2017-10-11
    published2017-10-11
    reporterRoot
    titleNetwork Time Protocol Broadcast Mode Poll Interval Enforcement Denial of Service Vulnerability(CVE-2016-7428)

Talos

References