[ntp:hackers] [Pool] NTP CVE patches?

Harlan Stenn stenn at ntp.org
Mon Oct 26 20:01:36 UTC 2015


Miroslav Lichvar writes:
> On Sat, Oct 24, 2015 at 01:09:06AM +0000, Harlan Stenn wrote:
> > Is a pool list the right place for this discussion?
> 
> Yes, there are people who are running public NTP servers and have a
> lot of experience with abusive clients, rate limiting etc. They may
> have feedback on the proposed changes and test them before they are
> included in the ntpd code.
> 
> > It may be that the server operator should stop using 'restrict kod
> > limited'.  But it's their choice to use it, and it was the client's
> > choice to use that server.
> 
> Are you saying clients should be able to detect if the server is
> vulnerable to this attack and avoid it? That doesn't seem right to me.

No.  I'm saying that the client chooses their servers.  If the client
chooses to use the pool, then they know they're getting "pool service".
If the Pool decides that member servers may use 'restrict kod limited'
then that's fine and this situation *may* happen.  If clients use
'server' lines to get pool servers, they will probably suffer more in
this case.  If they clients use the 'pool' directive then I believe the
situation will sort itself out automatically.

I have another mitigation for this problem that we'll be testing between
now and January.

> If the rate limiting as currently implemented is vulnerable, I think
> it should be either removed or fixed. It seems in DNS they were able
> to fix it.

Yes, and I'm happy to fix this sooner and it will require IETF working
group changes to the v4 spec.

> > > I think it also creates a new problem that an attacker could spam the
> > > client's syslog with these messages and fill the disk. Harlan, could
> > > you please consider adding a rate limit for the message to prevent
> > > that?
> > 
> > How far do we go?  syslogd already has code for clogging attackss.
> 
> Which is used on all systems supported by ntp and the rate limiting
> is enabled by default there? Wouldn't this be useful for an attacker
> to hide important information, like clock being stepped or peers
> becoming unreachable?

Are we talking about the same syslogd here?

Are you arguing for more complexity and bloat in ntpd?

Let's cut thru this.  What do you propose as a solution?

> The point is that as far as I know it wasn't possible to trigger a log
> message with a spoofed packet before and now it is. The users should
> at least be warned about this.

It's not *all* spoofed packets, it's not even about spoofed packets.

I've got an initial report of this change detecting what seem to be
unsolicited extra NTP packets from a Cisco router.

I've been trying to get a rewrite of our logging/debugging code for
years.  It's a massive job, and the biggest and hairiest part of this
job is coming up with a clean and useful design that will do what we
think we want.  Once that's done, it will "just" require a thorough
sweep of the code to do the cutover.

> > If the client is the victim of a DoS attack from forged sources, that's
> > something to report to the server operator and network operators.
> 
> Realistically, what they can do about it?

Report it to the server operators and network operators.  From there,
who knows?

> > > As for fixing the CVE, the NTPattack paper suggests to not drop all
> > > packets from rate limited clients, but reply randomly (similarly to
> > > RRL in DNS) to some percentage of the requests that appear to be
> > > coming from the client, so it will not be completely starved.
> > 
> > KoD packets do not have valid time stamps, so this won't work.  What
> > might work is to have a % of these KoD RATE response get answered.  But
> > there are problems with this too, if the source IP is being forged.
> 
> The proposal is to reply only to a fraction of the requests (chosen
> randomly) if restrict limited is enabled and the limit is reached.
> If also restrict kod is enabled, the fraction of the replies (chosen
> randomly) would be KoD RATE packets, but most of the replies the
> client would get would still be useful for synchronization.

Yes, and we'll be doing this (patches welcome) and it will require an
update to the RFC.

> There would be a change in the case of abusive clients though.
> Currently, if a client is always sending its requests too frequently
> and it doesn't fall off the monitoring list, it will get only KoD
> replies, which don't have the server's time. I think the intention was
> to let such clients drift away from true time, the user notice the
> clock is wrong, investigate the problem and get the implementation
> fixed. I'm wondering if that ever happened.

What part are you wondering about?  Not many folks seem to have used
KoD, as best as I can tell.

> > The best idea I've had is that if a client is getting unexpected replies
> > from a server that it send a query packet before the server might start
> > to send KoD responses, as there's a decent chance that the server might
> > soon stop responding to packets claiming to be from the client/target IP.
> 
> I'm not sure how would that help. When the client gets a reply to a
> spoofed request, it may already be blocked and it won't get any
> further replies to its own requests. Also, couldn't be this behavior
> (sending new request when a bad reply is received) exploited for some
> other attacks?

Blocked as the result of a single packet?

If the client is configured with an inadequate number of servers then
what can we do and how far should we go to "help" them?

Please propose a solution.

> > Also think about the consequences of what you are proposing - the
> > suggestion is that if a KoD RATE is received, there's a chance that if
> > we just ask often enough, we'll eventually get a valid response.  This
> > will *encourage* more traffic to a server for non-compliant NTP clients.
> 
> Yes, that is a possibility. It would definitely need to be tested
> first on a public server to see how the clients react when they are
> under the attack and get responses only to a fraction of their
> requests.

H


More information about the hackers mailing list