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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Wed Sep 14 18:39:12 UTC 2016


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

--- Comment #12 from Matthew Van Gundy <mvangund at cisco.com> 2016-09-14 18:39:12 UTC ---
(In reply to comment #10)
> But believe it or not, the diff+comp code handles the era rollover ;) hint:

Ack!  Got it.

The fix against TALOS-CAN-0131 appears to be good.  Because
`peer->bxmt` is not updated until after authentication is verified,
the spoofed packets cannot move `peer->bxmt` forward causing
legitimate broadcasts to be rejected as `non-monotonic`.

See: broadcast-dos-bxmt.syslog.gz, broadcast-dos-bxmt.pcap


It also appears that the TALOS-CAN-0130 works as expected.
Spoofed packets are rejected with messages such as:

    Sep 14 17:55:15 vagrant-ubuntu-trusty-32 ntpd: 14 Sep 17:55:15 ntpd[12719]:
receive: broadcast packet from 192.168.33.10 arrived after 2, not 8 seconds!

and the association remains functional as long as the peer has been
configured with `disable unpeer_digest_early`.

See: broadcast-dos-timelastrec.syslog.gz, broadcast-dos-timelastrec.pcap


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?


I also happened to encounter a "known issue".  After running the
broadcast-dos-bxmt attack for quite a while, the attack packet
send times happened to match up precisely with the poll period
and began to cause the association to flap causing a DoS
condition.  This is because the testbed was configured with
`enable unpeer_digest_early` causing any unauthenticated incoming
packets that were not rejected for arriving too early to tear
down the association.  I had to configure `disable
unpeer_digest_early` in further testing.

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