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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Thu Sep 15 17:24:00 UTC 2016


https://bugs.ntp.org/show_bug.cgi?id=3114

--- Comment #21 from Matthew Van Gundy <mvangund at cisco.com> 2016-09-15 17:24:00 UTC ---
(In reply to comment #18)
> Oh! Yes. Looking at the old code, one can see that the first BC packet would be
> dumped because of the monotonic-check. (The highest bit in the time stamp is
> already set, and the peer's bxmt is zero: being more than the half interval
> ahead accounts to being in the past.)

I don't think it was an initial value problem.  The initial value of peer->bxmt
gets set correctly just after newpeer() is called during association
mobilization (when handling case AM_NEWBCL).  Also, peer_clear() was patched to
preserve peer->bxmt when peer->hmode == MODE_BCLIENT.

I think the problem is that, if the client executes an initial volley and the
clock is stepped during the initial volley, peer->hmode != MODE_BCLIENT so
peer->bxmt isn't preserved.

I think your latest patch solves the case for when peer->bxmt gets cleared. 
However, we could just preserve peer->bxmt in peer_clear() if peer->hmode ==
MODE_BCLIENT || (FLAG_BC_VOL & peer->flags).  The one caveat to this is that it
looks like there may be a code path in process_packet() where FLAG_BC_VOL is
cleared without peer->hmode being updated to MODE_BCLIENT:

        /*
         * When calibration is complete and the clock is
         * synchronized, the bias is calculated as the difference
         * between the unicast timestamp and the broadcast
         * timestamp. This works for both basic and interleaved
         * modes.
         * [Bug 3031] Don't keep this peer when the delay 
         * calculation gives reason to suspect clock steps.
         * This is assumed for delays > 50ms.
         */
        if (FLAG_BC_VOL & peer->flags) {
            peer->flags &= ~FLAG_BC_VOL;
            peer->delay = fabs(peer->offset - p_offset) * 2;
            DPRINTF(2, ("broadcast volley: initial delay=%.6f\n",
                peer->delay));
            if (peer->delay > fabs(sys_bdelay)) {
        bcc_init_volley_fail:
                DPRINTF(2, ("%s", "broadcast volley: initial delay exceeds
limit\n"));
                unpeer(peer);
                return;
            }
        }

-- 
Configure bugmail: https://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