Bugtraq mailing list archives
Re: Security Hole in Axent ESM
From: caskey () TECHNOCAGE COM (Caskey L. Dickson)
Date: Tue, 1 Sep 1998 16:40:40 -0700
On Mon, 31 Aug 1998, Jeffrey Hutzelman wrote:
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.Before you reinvent the wheel or try to change any kernel interfaces related to time synchronization, I'd suggest you take a look at http://www.eecis.udel.edu/~ntp, which includes a complete description of the Internet-standard Network Time Protocol and how it works, including a reference implementation. This is perhaps the single most important program that actually _uses_ those interfaces, and it uses them to do fairly complex corrections that allow the time to be readjusted while still being monotonically increasing.
I agree that NTP does a very good job of solving the problem of managing time syncronization. The issue that I was trying to address is the possibility of attacks on a system that are date related. There are the two basic forms of attack; forwards and backwards. Setting the clock back can be used to cover one's tracks from a breakin attempt (trojans, etc.) while both can be used for various DoS attacks against servers. Consider the two examples below: Certain database systems use timestamps in table entries to determine whether or not the row is still valid. A start time and an end time determine whether or not the record is current. The amount of havoc that could be caused by an attacker who either shifts the time backwards, causing new records to be erroneously entered with past 'start' times, as well as shifting the time forwards so that while the time is in the future, records are flagged with end dates in the future. Once the clock is set back records that should have been deleted are now present again. Another attack could be used against systems that use near any form of public key certificates. Set the time forward to a point past the expiration of the certificate and one could cause trouble with someone's web server. Whatever scheme is devised to prevent time attacks must still allow for drift correction via various time control & syncronization mechanisms--such as NTP. Are there any systems that have solved the dual problem of 1) managing drift and lag and 2) preventing an attacker from being able to cause 'time warps' in the system? 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.
Current thread:
- Re: Security Hole in Axent ESM Jeffrey Hutzelman (Aug 31)
- Re: Security Hole in Axent ESM Caskey L. Dickson (Sep 01)
- Re: Security Hole in Axent ESM Taral (Sep 02)
- Re: Security Hole in Axent ESM Patrick (Sep 02)
- Borderware predictable initial TCP racer-x () ALTAVISTA NET (Sep 02)
- Re: Borderware predictable initial TCP Aggelos P. Varvitsiotis (Sep 03)
- Web servers / possible DOS Attack / mime header flooding Laurent FACQ (Sep 03)
- Re: Web servers / possible DOS Attack / mime header flooding Vanja Hrustic (Sep 03)
- wwwboard.pl vulnerability bugtraq (Sep 03)
- Re: Web servers / possible DOS Attack / mime header flooding Rich Wood (Sep 03)
- Re: Web servers / possible DOS Attack / mime header flooding Daniel Leeds (Sep 03)
- Re: Web servers / possible DOS Attack / mime header flooding Lars Eilebrecht (Sep 03)
- Re: Security Hole in Axent ESM Taral (Sep 02)
- Re: Security Hole in Axent ESM Caskey L. Dickson (Sep 01)