Re: Security Hole in Axent ESM

[caskey () TECHNOCAGE COM (Caskey L. Dickson)]

On Mon, 31 Aug 1998, Andy Church wrote:

> > Andy Church <achurch () DRAGONFIRE NET> wrote:
> > > One way I could see to
> > > make this more effective would be to use 64-bit times and disallow both
> > > setting the clock back and changing the top 2 bits to anything other than
> > > zero.  This would break the rollover attack without causing any premature
> > > Y2k-like problems (2^62 seconds ~= 10^13 years).
> >
> > This is still a DOS of sorts, as you can set the clock to 2^62-1, and
> > then it will be impossible to return the clock to the correct time
> > without rebooting.  Many things will probably be unhappy to find
> > themselves 10^13 years in the future.
>
>      Good point; I obviously hadn't thought that far.  I suppose you could
> just not let the clock be set at all--that would pretty cleanly stop
> clock-setting problems. (:
>
>      Come to think of it, aside from adjusting for clock drift, there
> shouldn't be any need to set the system clock under normal circumstances.
> If there were a system call like adjtime() which set a _continuous_ (not
> one-time) drift adjustment--for example, telling the kernel to adjust
> forward or backward one second every N seconds--then you could set that
> (and maybe the clock as well) at boot time, then disallow all clock
> adjustment functions, and you should be okay.  Linux looks like it has an
> adjtimex() that works something like this, though I don't have a man page
> for it.

The issue of drift correction is important, however the gradual change
technique employed in Linux adjtimex() is a constant one designed to make
up for inexactness in the system's ability to keep time.

Another, separate problem is the issue of arbitrary drift caused by
console messages.  It is my understanding that some unices turn off all
interrupts when dumping messages to the console and as such can cause the
timer to miss a beat.  Such is the reason for timed and many other
collaborative clock management daemons.

I would propose a more subtle mechanism where the system could be told to
gain or lose a certain number of seconds, but with an inbuilt maximum rate
of change (say one second every minute). This would allow for gradual
corrections that are arbitrary on top of a system for guarding against
constant drift.  "I need to make up 13 seconds." -> timetrim( 13 ).

This could all be layered on top of the existing Linux adjtimex however I
don't know what the limits of it are (i.e. could you make a system gain an
hour every second).  You would also need some method for re-setting the
time adjustment back to the 'no adjustment' adjustment when the desired
change has been made.

C=)

--------------------------------------------------------------------------
       There is hardly a thing in the world that some man can not
             make a little worse and sell a little cheaper.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com>       ///                pager.818.698.2306
TechnoCage Inc.                     ///|               gpg: 1024D/7BBB1485
--------------------------------------------------------------------------
  I didn't fight my way to the top of the food chain to be a vegetarian.