| Re: [chrony-dev] Traffic amplification with chrony commands |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] Traffic amplification with chrony commands
- From: Thomas Sprinkmeier <thomas.sprinkmeier@xxxxxxxxx>
- Date: Sat, 18 Jan 2014 06:11:24 +1000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=m33LlMXL811sslXdieT5Hey/Ew4cBxvfoixFraXCQyU=; b=Kd3SbM5POYRUvs4vXyGTt6f0K7/oYhjzLzFfg1fDBGoihCaNmKH2WQd21nXfKYOzHe naWx4z9pkDEj67dAK6m9CXyp8SFGvOpsNUQ+GiBncHtAF3F8f+ns/z/dw2eCTLWTEWLc +Q8bfVvBswgLaFDLVo36QmIcZh3dYU61WAg8zAq/Kv4cQ0/bEBJ8TEGna4CcZcSCS4BW J2SgUtXtimTWiwfBNtVooN4NA+jJbp0oz36tPcOjNE0zRDGCEFcSyycJ/Et2fs3RnLUK gzPO4iEJhw6JK8JSHZidiOmjBWpD3EHQtvUL4NBW+PDf6VWP9lE1uiKS7fXq7OVIH8R5 GLmg==
On 18/01/14 04:08, Miroslav Lichvar wrote:
On Fri, Jan 17, 2014 at 09:53:01AM -0800, Bill Unruh wrote:
Of course that would mean that chronyd would have to keep a library of current
nonces for each IP address that queries came in for, and one would have to
worry about a DOS against chronyc in which it was flooded with requests.
But one could put a rate limiting on that-- eg put in a delay of say 1 sec on
the response for the nonce, and only accept a certain number per second.
I don't like that. I think the point of using a nonce is that it
doesn't keep state for each client.
Without a per-address nonce an attacker could place a legitimate request from
their own IP address to learn the nonce, then fake requests from other IP addresses.
You don't need to store the nonce's though, simply calculate them as needed:
per-address-nonce = hash(secret | address)
If your nonce is only 32 bits then using anything stronger than MD5 is overkill.
You could try to future-proof by allowing the nonce to grow over time and switch
to a more secure hash if/when appropriate, but then you have to guard against
version-rollback attacks.
Easier might be to password the command. On the other hand, for a local query
one really would not want a password, so that would complicate the logic in
chronyd.
Hm, that's an interesting idea, to require password for all commands
if it's not from localhost and keep it as it is for localhost. It
wouldn't break compatibility and most of the users probably wouldn't
even notice it.
You'd be trading off your "potential amplification attack" problem for
"password management" and "remotely verifying passwords" problems^Wnightmares.
Given that some (many? most?) will likely reuse a valuable password you'll
make chrony a much more attractive target: attackers who might not care about the
amplification attack could target chrony to reveal passwords.
Thomas
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.