[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 
back-end segments.

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, 
in future.

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 mailing list