[ntp:hackers] 4.2.5p203 adds ntpq dumpcfg command

Danny Mayer mayer at ntp.org
Mon Aug 24 17:26:29 UTC 2009


Dave Hart wrote:
> On Sat, Aug 22, 2009 at 1:37 AM, Danny Mayer<mayer at ntp.org> wrote:
>> Dave Hart wrote:
>>> Definitely a SMP. Â Since it is currently available to anyone without
>>> authentication, restricting to a single directory seemed wise. Â Once
>>> it requires authentication, both the pathname and the
>>> non-existent-target restrictions can be removed as far as I know.
>> No. This is extremely dangerous. Paths need to restricted otherwise it
>> is a potential attack vector allowing people to overwrite the password
>> file, boot file, or anything else, particularly if ntpd is running as
>> root. Even within a root jail you are asking for trouble. The best
>> solution is to configure a write directory within the configuration file
>> and not allow that directory to be changed remotely.
> 
> So I take you also feel that "logfile" needs to be restricted from
> remote configuration as well, since it can be used to overwrite
> /etc/passwd and other fun files?  ntpq :config requires
> authentication, which probably the majority of users don't configure,
> but for those who do have it, you feel that the operator can not be
> trusted to avoid hosing himself?
> 
> In case it's not clear, I'm suggesting (still and again) that if
> dumping the configuration is restricted to authenticated operators,
> they can be trusted to overwrite any file they name, in any location.
> 

I'm not sure what the rush was to get this into 4.2.6. It could have
waited to the next release. This has not been thought through with all
of the possibilities and should have been done first. Pushing more and
more items into 4.2.5 is counter-productive since there are more things
that can be broken and these items need to be extensively tested and
delays the 4.2.6 release.

The first and easiest piece to do is to not allow it to overwrite
anything and that it *always* be a new file.

The assumption that the authentication isn't trivial to break is wrong
since it is easy to capture on the wire. There is no trust that you
should assume on the internet. The configuration file should be assumed
to be private but the consequences of doing it wrong are potentially
larger. If I want the configuration information and this is on an http
server I could easily have it write to the http server's paths and then
read it via http. Let's be honest here, the number of people who make
frequent dynamic changes to their configurations is very small. It's
mostly set and forget and mostly on clients.

Let's draw back and properly review this before we put it into production.

Danny



More information about the hackers mailing list