Re: [chrony-dev] Traffic amplification with chrony commands

[Håkan Johansson <f96hajo@xxxxxxxxxxx>]

On Fri, 17 Jan 2014, Bill Unruh wrote:

> On Fri, 17 Jan 2014, Miroslav Lichvar wrote:
>
> > On Thu, Jan 16, 2014 at 07:50:33PM +0100, H???kan Johansson wrote:
> > > I would suggest what I think is called a nonce value.
> >
> > I think that's what ntpd uses with the new mrulist command. The
> > advantage over the simple padding approach would be saved bandwidth,
> > but I'm not sure it's really worth the complication in the protocol.
> > It would break compatibility with older chrony versions in any case.
> >
> > > - Server picks some random number/string and keeps that.
> > > - Client sends a response, without nonce.
> > > - Server takes the apparent client IP and the string and makes some hash
> > >   of that, the nonce value for that client IP.
> > > - Server sends very short response to client, telling: if you want to
> > >   talk to me from your IP (whatever it is), you have to also give this
> > >   nonce.
> > >
> > > - Client sends request again, now with nonce.
> > > - Server checks nonce, and if happy sends the real response.
> > >
> > > The server could pick a new random number/string every few hours or
> > > minutes or so.
> >
> > In chrony we would have to use MD5 as the hash unless the dependency
> > on nss/tomcrypt was no longer optional. How often would the random
> > number need to be regenerated considering MD5 is no longer secure? I'd
> > rather avoid having to think about that. :)
>
> MD5 IS still secure for this purpose. It is deprecated, and it is possible to
> craft two different messages which will have the same MD5 value (so one 
> should
> never md5 sign a text which was given to you by someone else without making
> some change to it) plus it has some features which give people a slight 
> worry,
> but there have been no attacks which solve the "given md5 hash, find a text
> which has that hash" problem. If one has a choice one should use something
> else, but if one does not, I would not worry very much.

Even if the advanced mathematics is available to the attacker to figure 
out what the nonce would be for the attacked IP, this would need some 
input data.  The only data possible would be nonces for other IPs, which 
it actually could get (non-spoofed addresses), if performing a distributed 
information collection.  But then needed for each chronyd box the attack 
network wants to use as amplifier.

Changing server secret random number/string every hour should frustate 
even such (impossible) schemes enough.

As long as chronyc is capable to handle the case where a nonce happened to 
change, good clients have no problem.

> > > In case the source IP is faked, the only thing that will be sent to
> > > the attack target is a small nonce.  So it should become a deflation
> > > attack.
> >
> > Yes, if the request is larger than the reply with nonce.
>
> I think his proposal is that the first reply is just the nonce.

Yes, that would be the idea.  The response being some leading byte(s) to 
say that it is a nonce, and the nonce.  Nothing more.  I suppose even 32 
bits of nonce should be quite enough.

The advantage is that the nonce method requires no state at the server 
except for the random number/string, and just the nonce state at the 
client.  The overhead is a need for the server to calculate an somewhat 
expensive md5.  But my semi-recent machine here makes 360 MB/s md5sum, 
which should be ~ 5M/s MD5 (64 bytes per MD5 round).

With the information collection problem for an attacker above, it is 
probably so that also a much cheaper pseudo-random number generator could 
be used instead of MD5.  Say that one uses 8 secret numbers as seeds, each 
together with a piece of the apparent client IP creating 8 new numbers.