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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]




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.

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/