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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Wed Sep 14 19:34:05 UTC 2016


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

--- Comment #18 from Juergen Perlinger <perlinger at ntp.org> 2016-09-14 19:34:05 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> Ack!  Got it.

 ;) This kind of logic is always mind-boggling.

> 
> However, it appears that there is something wrong with the logic when
> stepping.  After the client STEPs its clock
> 
>     Sep 14 14:54:00 vagrant-ubuntu-trusty-32 ntpd[11993]: 0.0.0.0 c61c 0c
> clock_step +2.026588 s
>     Sep 14 14:54:00 vagrant-ubuntu-trusty-32 ntpd: 14 Sep 14:54:00 ntpd[11993]:
> 0.0.0.0 c61c 0c clock_step +2.0265
>     88 s
>     Sep 14 14:54:00 vagrant-ubuntu-trusty-32 ntpd: event at 185 0.0.0.0 c61c 0c
> clock_step +2.026588 s
> 
> all subsequent broadcast packets are rejected with:
> 
>     Sep 14 14:54:09 vagrant-ubuntu-trusty-32 ntpd[11993]: receive: broadcast
> packet from 192.168.33.10 contains non-monotonic timestamp: 0000000000.00000000
> -> 0xdb83e311.93c5f637
> 
> See: step-problem.syslog.gz
> 
> Could this have to do with throwing away timestamps as mentioned
> in Comment #11?
> 
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.)

BUT: the previous code set the bxmt time stamp nevertheless before bailing out.
So at least the *next* BC packet would be used... Since we now make sure we
update bxmt only if the packet is valid, this never happens due to a
chicken/egg problem. I guess we have to make sure we execute the check only if
p->bxmt is not all-zero, because otherwise the chicken never hatches.

Which leaves us a few problems when really stepping the clock backwards:
Because now the time stamps we get are 'before' the last BC we accepted, BC
packets will be rejected until the clock has recovered the time interval it had
to step backwards. And *this* will be a real bugger if the step is a major one.
OTOH, most system that need a major step after startup come up late because of
missing battery-backed clocks or alike, and forward steps are not the real
problem unless the jump is more than 68 years ahead.

I'll try to make sure the BCLIENT chicken can hatch, but the back-step problem
needs more consideration before we can call it a day.

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