[ntp:security] Re: Concerning a possible bug in the 'ntp' package
mayer at ntp.isc.org
Sat Sep 3 02:52:29 UTC 2005
David Wagner wrote:
>>Well, while it's all possible, why would anyone who could break in
>>bother to do that. They basically would do a lot more damage elsewhere,
>>though I get your point.
> These are locally exploitable attacks. The attacker has to have a
> local account before he can exploit them. There are two ways that
> an attacker might be able to get a local account:
> 1) Legitimately. On a multi-user system, the attacker might be a
> legal user who has a valid (non-root) account. These vulnerabilities
> show how an attacker with a non-root account can do things to the
> system that non-root users should not be able to do.
> 2) Illegitimately. The attacker might be able to exploit some hole
> in some other service that gives the attacker non-root access to the
> system. The attacker might then follow that up by exploiting the
> ntpd vulnerabilities to do extra damage to system files that aren't
> writable by that non-root account, effectively gaining root-level
> access. The latter is known as a "privilege escalation" attack.
That one I see on windows all the time.
> Here is a good question to ask yourself: Is it your position that ntp is
> not intended to be safe to run on any multi-user system, and that users
> should never use it on any multi-user system, if they care about security?
> If so, it seems like this would be a good thing to mention prominently
> in your documentation somewhere. (I confess I wouldn't have expected
> this to be the intent, but only you know what the intent is.)
You are right. ntp is meant to run on any system, whether single user,
mulltiuser or server. As such it could potentially be an attack vector
from anywhere. We do care a great deal about security and I need to get
my head around it. We are planning to go to an asynchronous resolve and
that would really get rid of the mk(s)temp issue. It's a question of when.
We can make use of a random number generated file name if that would
make it safer, at least for the time being, but it still would have the
potential of being predicted, just a much smaller target of vunerabilities.
> I apologize if it sounds like I'm giving you a hard time. I don't really
> care what you do about this bug, but it seems like it would be better
> if any decision you make is informed by all the facts. I just want to
> make sure you have all the relevant information.
And I thought I was giving you a hard time. Understanding is 90% of the
problem. Solving it is the other 10%.
More information about the security