[ntp:hackers] More on configuration rewrite
David L. Mills
mills at udel.edu
Fri Mar 3 18:27:04 UTC 2006
In principle, the configuration rewrite has nothing to do with access
control or authentication; however, there are some serious issues
involved. The following are among the design requirements.
1. The configuration grammar contains all the current commands and
subcommands, but only the simulator actually uses it now. It is designed
to be easily changed and augmented without changing the parser or
2. The data structure representing the configuration file is constructed
in its entirety before the back-end segments, including DNS, are called.
This, dear hearts, gets rid of the temporary file and allows new options
during the configuration process. This makes it possible to tack on
per-system options now to be per-server options, such as restrict bits,
3. As the entire configuration tree is retained, it should be possible
to modify it on-fly without restarting the daemon. It would be possible
in general to send configuration commands directly from ntpq and in the
same configuration file format; however, there is a really serious
authentication problem with this. I insist that the security model has
the same strength as the security model for host access, which means ssh
to most of us.
There are two approaches for remote configuration authentication:
1. Forbid it; require the perp to ssh in and run a utility program which
modifies and activates the configuration tree directly.
2. Include ntpq messages in the security protocol just as ordinary NTP
packets. This might not be as hard as it looks, especially if only the
symmetric key cryptography is necessary.
When all this is done, the only thing left for ntpdc to do is the
monlist function. The function is most useful when the LRU list is very
large, like 600 entries, but this results in a serious burst of 70-80
packets, which makes it almost certain that some will be dropped. This
function is a serious clogging vulnerability. In its present form a bad
guy could send fake LRU requests as fast as he/she can with source
address his college professor's home computer.
The only answer to this is to move the LRU data to the filegen facility
and retrieve them later via the host access security model. There still
has to be a way to authenticate requests to dump the table. The table,
and perhaps other statistics as well, could be retrieved via web pages,
secure or not. I rather like that approach, or simply mail them to a
designated (authenticated) address.
There are some statistics, like useage tallies, that are now returned
only by ntpdc. They can be returned individually as system variables
with ntpq or as a group using new commands designed for this purpose.
More information about the hackers