[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