[7853] in bugtraq
Re: Security Hole in Axent ESM
daemon@ATHENA.MIT.EDU (Caskey L. Dickson)
Tue Sep 1 20:15:07 1998
Date: Tue, 1 Sep 1998 16:40:40 -0700
Reply-To: "Caskey L. Dickson" <caskey@TECHNOCAGE.COM>
From: "Caskey L. Dickson" <caskey@TECHNOCAGE.COM>
X-To: Jeffrey Hutzelman <jhutz+@CMU.EDU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <ML-2.3+1.904618318.113.jhutz@minbar.fac.cs.cmu.edu>
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.
