[ntp:security] [Bug 3114] Broadcast Mode Replay Prevention DoS
bugzilla-daemon at ntp.org
bugzilla-daemon at ntp.org
Mon Nov 14 21:39:59 UTC 2016
--- Comment #26 from Matthew Van Gundy <mvangund at cisco.com> 2016-11-14 21:39:59 UTC ---
(In reply to comment #23)
> 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.
Fair enough. I believe my original intention was that to indicate that there
is a floor under the minimum poll period.
> 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".
The crux of this issue is that the timestamps are being updated by
"unacceptable" packets that are discarded in addition to "acceptable" packets.
> 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.
My mention of unpeer_digest_early was merely to indicate the configuration that
was necessary to test the functionality. Though, I'm curious, what risks are
increased by disabling "unpeer_digest_early"? I'm not aware of any.
> 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
> 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?
If it is the case that broadcast mode should only be used in trusted
environments, then I agree that attempts at replay (and DoS) prevention are
somewhat superfluous. Should RFC 5905 and the NTP documentation be updated to
indicate that broadcast mode should only be used in trusted environments
without malicious actors? The closest thing I've seen is
https://www.eecis.udel.edu/~mills/ntp/html/authentic.html which doesn't really
convey that broadcast is unsafe outside of trusted networks (in fact, it
assumes an untrusted network):
In the case of unsolicited packets which might consume
significant resources, such as broadcast or symmetric mode
packets, , authentication is required, unless overridden by a
disable auth command. In the current climate of targeted
broadcast or "letterbomb" attacks, defeating this requirement
would be decidedly dangerous.
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