On Mon, Jan 13, 2014 at 03:13:44PM -0800, Bill Unruh wrote:
> How is chrony on the amplification attacks like those against ntpd? As I
> understand it, the server queries can return far more information (ie
> many
> more bytes) than is in the query packet. This allows an attacker to send
> queries to ntpd with someone else's IP address in the slot, so ntpd will
> send
> back far more informtion to that spoofed address than was in the query
> packet.
> One can thus send out a small packet and have a huge packet delivered to
> that
> spoofed address.
It seems the chrony cmdmon protocol has this problem too, although
it's not as bad as the monlist command from the ntpd control protocol.
> chrony also has the chronyc type queries which can be sent to a remote
> IP.
> Fortunately chronyd's default is to not accept queries from anything but
> the
> local machine, instead of ntpd's default of accepting queries from
> the world. However, if you do happen to make chronyd open to
> accepting queries from the
> world, you can get rather huge multiplication. The chronyc "help" for
> example put out
> something like 3000 characters for a simple query. (although I am not
> sure
> that the remote chronyd actually accepts the help command. Certainly
> chronyc
> seems to answer this one locally).
The help command just prints a message stored in chronyc, no packets
are exchanged with the server.
I've checked packet lengths for all commands and the biggest offender
is MANUAL_LIST (chronyc manual list), which may amplify the traffic by
up to factor of 17.2. The second worse is CLIENT_ACCESSES_BY_INDEX
(chronyc clients) with factor of 6.5, but the client has to be
authenticated to get the reply. Everything else is below 3. In the
protocol there is at most one reply per request.
The MANUAL_LIST command is used to list up to 32 manual measurements,
which were entered by the SETTIME command when the manual mode is
enabled. It's disabled by default and I think it's unlikely that
someone would use the manual mode on a system connected to internet.
So, what do we do? Pad all requests so they are never smaller than
their replies? It wouldn't be very difficult to implement, but it
would obviously break compatibility with older chrony versions. An
easy fix for MANUAL_LIST would be to require authentication.
Any suggestions?
The following table has details on all currently supported commands.
The columns are name, flag if it's open to any client or requires
authentication, minimum length of the request in IPv4 packet, maximum
length of the reply in IPv4 packet and the ratio of the two values.
MD5 authentication is assumed for commands with AUTH.
MANUAL_LIST OPEN 48 828 17.2
CLIENT_ACCESSES_BY_INDEX AUTH 72 468 6.5
TRACKING OPEN 48 132 2.8
SOURCESTATS OPEN 52 112 2.2
SOURCE_DATA OPEN 52 104 2.0
RTCREPORT OPEN 48 84 1.8
ACTIVITY OPEN 48 76 1.6
N_SOURCES OPEN 48 60 1.2
NULL OPEN 48 56 1.2
WRITERTC AUTH 64 72 1.1
TRIMRTC AUTH 64 72 1.1
SETTIME AUTH 76 84 1.1
RESELECTDISTANCE AUTH 68 72 1.1
RESELECT AUTH 64 72 1.1
REKEY AUTH 64 72 1.1
MODIFY_MAXUPDATESKEW AUTH 68 72 1.1
MANUAL_DELETE AUTH 68 72 1.1
MANUAL AUTH 68 72 1.1
MAKESTEP AUTH 64 72 1.1
DUMP AUTH 68 72 1.1
DFREQ AUTH 68 72 1.1
CYCLELOGS AUTH 64 72 1.1
LOCAL AUTH 72 72 1.0
DOFFSET AUTH 72 72 1.0
LOGON OPEN 60 56 0.9
DEL_SOURCE AUTH 84 72 0.9
CMDACCHECK AUTH 84 72 0.9
ACCHECK AUTH 84 72 0.9
MODIFY_POLLTARGET AUTH 88 72 0.8
MODIFY_MINSTRATUM AUTH 88 72 0.8
MODIFY_MINPOLL AUTH 88 72 0.8
MODIFY_MAXPOLL AUTH 88 72 0.8
MODIFY_MAXDELAYRATIO AUTH 88 72 0.8
MODIFY_MAXDELAYDEVRATIO AUTH 88 72 0.8
MODIFY_MAXDELAY AUTH 88 72 0.8
DENYALL AUTH 88 72 0.8
DENY AUTH 88 72 0.8
CMDDENYALL AUTH 88 72 0.8
CMDDENY AUTH 88 72 0.8
CMDALLOWALL AUTH 88 72 0.8
CMDALLOW AUTH 88 72 0.8
ALLOWALL AUTH 88 72 0.8
ALLOW AUTH 88 72 0.8
ONLINE AUTH 104 72 0.7
OFFLINE AUTH 104 72 0.7
BURST AUTH 112 72 0.6
ADD_SERVER AUTH 116 72 0.6
ADD_PEER AUTH 116 72 0.6
--
Miroslav Lichvar
--
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.