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

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Oct 28 03:07:29 UTC 2016


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

--- Comment #23 from Harlan Stenn <stenn at ntp.org> 2016-10-28 03:07:29 UTC ---
Matt,

I'm going to comment on a number of things.

First, broadcast mode is useful in TRUSTED ENVIRONMENTS.  It specifically uses
authentication by default.  There are known risks for its use in hostile
environments.

In comment #1 you say:

> 2. The packet was received before a full poll interval has elapsed
>    since the last broadcast packet was received from the packet's
>    sender.  i.e. A server cannot ingress packets more frequently than
>   `peer->minpoll`.

The 2nd sentence is correct, but inaccurate.  The broadcast minpoll need not be
the same value as the broadcast maxpoll.  The condition is minpoll <= maxpoll.

I submit that a better sentence is:  i.e. A server cannot ingress packets more
frequently than the current active broadcast association's poll interval.

Next, the reason for updating bxmt on each "acceptable" packet is specifically
to avoid the situation where a packet with a future timestamp prevents the
client from syncing until the clock reaches that future moment.  That's another
DoS vector.  We can tweak the definition of "acceptable".

We log the receipt of unexpected packets.  We tell people to monitor their ntpd
instances.  This monitoring should include their log files.

The current "fuzz" on broadcasts is 3 seconds.  We picked that number as
smaller numbers caused too many log messages.  But we *could* let folks tweak
this number.

You also talk about unpeer_digest_early.  This is a "choose your poison" issue.
 The default behavior protects against one form of abuse, creating increased
risk from the attack vector you describe.  Disabling unpeer_digest_early
reduces the risk of the vector you describe, but it increases other risks.

If a broadcast server steps its time, that step could be either forward or
backward.  We want clients to notice and follow this as soon as possible. 
Granted, we're talking about broadcast mode here, so it will take a number of
poll intervals for this to be noticed.  It seems to me we don't want to extend
the time it takes for a broadcast client to synchronize to its broadcast
server.

If folks are running broadcast mode and are seeing these attacks, the first
thing they should do is evaluate whether or not they really should be using
broadcast mode.  If that's still desirable, about the only other thing we can
do is decide what else we can tweak.  This might be the fuzz, this might be
something else.

But broadcast mode is not the best choice for hostile environments.

Do you think I'm missing something?

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