OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: Security Hole in Axent ESM

Re: Security Hole in Axent ESM

Andy Church (achurchDRAGONFIRE.NET)
Mon, 31 Aug 1998 16:39:54 EDT 

>Andy Church <achurchDRAGONFIRE.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.

  --Andy Church                  | If Bell Atlantic really is the heart
    achurchdragonfire.net       | of communication, then it desperately
    www.dragonfire.net/~achurch/ | needs a quadruple bypass.