[7840] in bugtraq
Re: Timesetting ... Re: Security Hole in Axent ESM
daemon@ATHENA.MIT.EDU (Henry Longmore)
Tue Sep 1 14:57:58 1998
Date: Mon, 31 Aug 1998 18:42:30 -0600
Reply-To: Henry Longmore <henry@CUMULUS.NET>
From: Henry Longmore <henry@CUMULUS.NET>
To: BUGTRAQ@NETSPACE.ORG
-----Original Message-----
From: Andy Church <achurch@DRAGONFIRE.NET>
To: BUGTRAQ@NETSPACE.ORG <BUGTRAQ@NETSPACE.ORG>
Date: Monday, August 31, 1998 4:10 PM
Subject: Re: Security Hole in Axent ESM
>>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.
This would be great if clocks lost time at a constant rate. I'm afraid not
many do,
however. Without a constant rate, an algorithim to adjust for time drift
might be
rather complex (and CPU time consuming).
I think the best way to do this for tamper_resistant quality would be to
ONLY set the clock at boot time --thus requiring access to the physical box
to set time, and require a password to do so, not relying on permissions
(sort of like BIOS setup passwords on x86 architecture)
