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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Tue Sep 13 23:36:35 UTC 2016


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

--- Comment #5 from Matthew Van Gundy <mvangund at cisco.com> 2016-09-13 23:36:35 UTC ---
(In reply to comment #3)
> I'm working my way through the diff manually, since it is against the GIT repo
> which is not quite the 4.2.8p8 release. AFAIK there has been trouble with the
> GIT export, which makes things awkward to handle. Anyway, I'll cope somehow.

I'm sorry about that.  I'm guessing someone edited the disclosure in a
non-whitespace-preserving editor before it made it out the door. :-/  I can
provide a patch against 4.2.8p8 if you like.

> But there is at least one issue: The snippet in
> 
> @@ -1348,9 +1347,8 @@ receive(
> 
> damages the compare op. Since the NTP time scale is seconds since 1900 (mod
> 2^32), a simple compare is not enough to handle the wrap-around / overflow. One
> has indeed to take the difference (mod 2^32) and check if the result is
> negative. So I won't apply that fragment, as it is definitely wrong.

I'm pretty sure that the current code doesn't handle wrap-around / overflow
gracefully either, so I think they're equivalent on that criteria.  I changed:

    tdiff = p_xmt;
    L_SUB(&tdiff, &peer->bxmt);
    if (tdiff.l_i < 0) { ...

to

    if(!L_ISGEQU(&p_xmt, &peer->bxmt)){ ...

because the first code has a subtle bug.  If the incoming timestamp is
non-monotonic (p_xmt < peer->bxmt), then it works as expected (tdiff.l_i < 0 ==
TRUE).  However, tdiff.l_i < 0 will also be true if p_xmt > peer->bxmt +
0x80000000.  So, if peer->bxmt currently contains a small value but a
legitimate incoming p_xmt is greater than 2^31, the incoming packet will be
rejected for having a non-monotonic timestamp.  This issue may have been
obscured by the fact that peer->bxmt was being updated by packets that were
failing the integrity check.  I changed it to an unsigned greater than or equal
comparison to ensure that packets meeting p_xmt > peer->bxmt + 0x80000000 would
not be rejected.

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