On Tue, 31 Jul 2001, Emmanuel Dreyfus wrote:

> > > Someone that compromised ntpd could use it to gain root?
> > And a compromised ntpd right now gives you what? The exact same thing? :-)
>
> The idea of /dev/clock is to get rid of this kind of problem. If we are
> sure that non root users cannot set the clock backward using /dev/clock,
> is it okay?

I understand what you're trying to do. I'm trying to say that you will
never be able to make it so that a compromised ntpd has no adverse impact
on system security. You can GREATLY reduce the impact of an ntpd
compromise - limiting it to just the time subsystem - (and I encourage you
to continue working on it for that reason!  :-) but I believe you will not
be able to completely close the hole.

I don't think that preventing setting the clock backwards will totally
prevent security problems. It will make the attacks more complicated, but
they can still happen.

Say I know of an ntpd compromise which will let me set the clock however I
want (and however we let ntpd set the clock, not backwards in your
example).  Say I'm in a kerberos environment, and I want into one machine.
If it's a large environment, chances are there are slave servers. So I set
one of the KDC's and the target machine's clocks forward, and watch an
authentication happen. I can then replay the authentication in the future
(when the slave's clocks catch up with where I set the clocks ahead to).

Yes, this is a more complicated attack, and much less likely than a simple
replay of a past log with a moved-back clock. But it is an attack.

Also, say there are times when ntpd NEEDS to set the date back (like say
there's a network outage, and the clock has drifted forward & needs to be
scooted back). Preventing ntpd from moving the clock back can, in such a
case, make it unable to do its job. So systems which need the clock set
right will fail.

So I think that as long as ntpd is able to do _anything_ with the system
clock, an ntpd vulnerability can be a security vulnerability in an
environment where time is used for replay protection.

Let me repeat myself though. I _do_ think making a /dev/clock is a good
thing. It will take the scope of ntpd vulnerabilites from the realm of a
compromised root daemon to the realm of a compromised system clock. With
/dev/clock, a compromised ntpd won't be able to say add ssh credentials to
the system, or say grab the system private key. :-) It just won't
_completely_ mitigate ntpd vulnerabilities.

Take care,

Bill