-----Original Message----- From: Andy Church <achurchat_private> To: BUGTRAQat_private <BUGTRAQat_private> Date: Monday, August 31, 1998 4:10 PM Subject: Re: Security Hole in Axent ESM >>Andy Church <achurchat_private> 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)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:39 PDT