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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Thu Oct 20 18:29:22 UTC 2016


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

Juergen Perlinger <perlinger at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1457|0                           |1
        is obsolete|                            |

--- Comment #22 from Juergen Perlinger <perlinger at ntp.org> 2016-10-20 18:29:22 UTC ---
Created attachment 1469
  --> https://bugs.ntp.org/attachment.cgi?id=1469
changes from 4.2.8p8 / shot 3

The initially suggested patch has one big problem: It potentially prevents the
daemon from stepping backward when the legitimate broadcast server steps back.
This should not happen often, but it is something to heed.

The proposed change is to ignore backsteps for the next 4 broadcast intervals,
based on the time of the last *valid* broadcast telegram reception point. A
backstep longer than that is delayed for at most 4 BC intervals in this way;
shorter backsteps will recover the 'lost time' sooner and the BC client is
bound to follow after some time. (Backsteps shorter than one BC interval will
go unnoticed anyway by the current code.)

So as long as the attacker cannot completely supplant the legitimate BC server,
the client should follow the server, based on the assumption that the replay
attack has to use captured BC messages from the past. If the attacker can
successfully supplant the BC server, all bets are off. But then, BC mode is for
trusted networks only.

Harlan the repo is in

    psp.ntp.org:~perlinger/ntp-stable-3114

This does *not* contain the changes for Bug 3113. Further comments welcome --
maybe that's not the last round.

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