[prev in list] [next in list] [prev in thread] [next in thread] 

List:       timekeepers
Subject:    Re: [Pool] NTP CVE patches?
From:       Miroslav Lichvar <mlichvar () redhat ! com>
Date:       2015-11-02 11:45:06
Message-ID: 20151102114506.GA30406 () localhost
[Download RAW message or body]

On Mon, Oct 26, 2015 at 08:01:36PM +0000, Harlan Stenn wrote:
> Miroslav Lichvar writes:
> > 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.

Which part of the RFC will need to be updated? I don't see anything
relevant to the rate limiting or KoD on servers there. From the open
source NTP implementations, it seems only ntpd implements the rate
limiting and its description wasn't included in the RFC.

The part on handling KoD packets on clients could definitely be
improved though.

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

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

Remove that log message or add a rate limit for it, e.g. allow only
one message per minute and the source. The fix for CVE-2015-7850 that
was included in 4.2.8p4 is a form of rate limiting. If it was extended
to allow multiple instances and check also time since last message,
maybe it could be used in this case too.

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

They can preach about BCP 38 and hope someday the internet will be
"fixed". That's probably all they can do.

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

Are you still interested in the patch? I can prepare one if NTF hasn't
assigned it to someone yet.

> > 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 part about not sending any useful timestamps to the client so it
drifts away and the user getting the implementation fixed.

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

The attacker can send a burst of requests to the server. By the time
the client gets a reply to the first packet, it may already be
blocked.

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

I don't think number of servers really matters here as the attacker
can send spoofed packets to all servers the client is or may be using.
I think the fix is, as you seem to agree, to make the attack pointless
by not completely starving the clients when they appear to be sending
too many requests.

-- 
Miroslav Lichvar
_______________________________________________
pool mailing list
pool@lists.ntp.org
http://lists.ntp.org/listinfo/pool
[prev in list] [next in list] [prev in thread] [next in thread]