[ntp:security] [Bug 3114] Broadcast Mode Replay Prevention DoS

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Tue Sep 13 04:57:02 UTC 2016


Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
           Priority|P5                          |P2
                 CC|                            |mvangund at cisco.com
              Flags|                            |blocking4.2.8+
           Severity|enhancement                 |critical

--- Comment #1 from Harlan Stenn <stenn at ntp.org> 2016-09-13 04:57:02 UTC ---

Network Time Protocol Broadcast Mode Replay Prevention Denial of Service

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


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

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

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      }
    1362      peer->bxmt = p_xmt;
    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

    - 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 <mvangund at cisco.com>
    Date: Tue, 26 Jan 2016 15:00:28 -0500
    Subject: [PATCH] Fix unauthenticated broadcast mode denial of service

     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(

    -     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",
              peer->bxmt.l_ui, peer->bxmt.l_uf,
    @@ -1359,8 +1357,6 @@ receive(

    -     peer->bxmt = p_xmt;
          if (bail) {
            peer->timelastrec = current_time;
    @@ -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.

:: Credit

Discovered by Matthew Van Gundy of Cisco ASIG.

:: Timeline

2016-09-13 - Vendor Disclosure
YYYY-MM-DD - Public Release

Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the security mailing list