[7828] in bugtraq
Re: Security Hole in Axent ESM
daemon@ATHENA.MIT.EDU (Andy Church)
Mon Aug 31 18:00:36 1998
Date: Mon, 31 Aug 1998 16:39:54 EDT
Reply-To: Andy Church <achurch@DRAGONFIRE.NET>
From: Andy Church <achurch@DRAGONFIRE.NET>
X-To: Michael Shields <shields@crosslink.net>
To: BUGTRAQ@NETSPACE.ORG
>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.
--Andy Church | If Bell Atlantic really is the heart
achurch@dragonfire.net | of communication, then it desperately
www.dragonfire.net/~achurch/ | needs a quadruple bypass.
