[ntp:security] [Bug 2901] Clients that receive a KoD should validate the origin timestamp field.

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Aug 28 05:19:28 UTC 2015


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

--- Comment #6 from Majdi S. Abbas <msa at latt.net> 2015-08-28 05:19:28 UTC ---
(In reply to comment #5)
> Well not really. If you are properly set up you get multiple packets from
> different servers and it's extremely hard for an attacker to do this to all of
> them. In any case, for DENY or RSTR codes the recipient of a kiss code packet
> is required to drop the association. For RATE it needs to reduce the frequency
> of queries.

        It turns out it's not that hard, at least in an IPv4 world where
we helpfully place the IP address of the server in the refid field.
For v6, provided the server is not publicly listed anywhere the
truncated hash protects it to some degree.  For public servers it's not hard
to pre-compute a table of hash entries, limiting the number of possible
v6 addresses to source an attack from.

> For ALL cases the recipient is required to drop the packet. The values of the
> timestamps cannot be used. I've had discussions with Dave Mills on some of
> this and it is clear that this is the design of the kiss codes. Under NO
> circumstances can the contents of the packets be used so even if there was a
> DOS attack these packets could not be used for anything to set the clock.

        This has nothing to do with setting the clock; it has to do with
validating that a KoD received actually came from our associated server,
and wasn't spoofed.  Since the origin TS comes from the client, using it
is not providing time service -- it just gives the client a way to 
validate bidirectional communication with the server.

> The biggest worry has been the clients that abuse the upstream NTP servers
> (this is especially a problem with government servers) and is far more
> important and required than possible attack vectors.

        At this point the biggest worry is going to be selective denial
of service attacks by spoofing chimes from a client towards their 
associated servers to trigger rate limits, thus knocking them offline.  
I have no answer there other than overprovisioning and generous rate 
limits.

> It doesn't matter, the packet needs to be dropped.

        The packet does not need to be dropped; the association needs to
be dropped, or at least rate limited, provided that the origin timestamp is 
the one the client sent, which helps to validate that it came from the server
(or at least an attacker with access to the network path.)

        Processing one timestamp out of the packet (which was originally
provided by the client to begin with), on the client itself, just to
validate the KoD, seems fairly safe.

> The problem raised is more theoretical than real. Any change would be
> detrimental to real live and busy systems.

        Unfortunately NTF is facing a series of soon-to-be-published
attacks around the KoD functionality.  Validating the origin TS on
the client may be the only way to save KoD in campus environments (it's
probably dead on the wider Internet after this publication.)

        Since the origin TS is copied to the transmit and receive TS
fields when sending a KoD, this involves no change to the KoD generation
code, so it should not affect deployed systems or harm anything in the field.

        It just allows us to slightly harden up the clients handling of a
received KoD by validating bidirectional communication.

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