[12735] in bugtraq
Re: local users can panic linux kernel (was: SuSE syslogdadvisory)
daemon@ATHENA.MIT.EDU (Paul Boyer)
Fri Nov 26 03:08:15 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Message-Id: <383C28D4.FB9066B4@paulboyer.org>
Date: Wed, 24 Nov 1999 19:05:08 +0100
Reply-To: Paul Boyer <Paul.Boyer@PAULBOYER.ORG>
From: Paul Boyer <Paul.Boyer@PAULBOYER.ORG>
X-To: "A. Steinmetz" <astmail@YAHOO.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
"A. Steinmetz" wrote:
>
> To add to Shafik's statement, now all you have to do to is to put a system
> under high (log) load for any attack to go possibly unlogged? This leaves
> me somewhat sleepless...
>
While missing some log lines could seem somehow not that risky, since
when your loghost get loaded like crazy you're alerted of an attack
anyway, I do agree with Shafik because those lines missing might cause
not only missing line but a risk of inconsistency.
<Linux specific>
I could make that trouble happen while testing by overloading the kernel
logging facility with a dumb logger ipchains policy looking like :
ipchains -I input -l;ipchains -I forward -j REJECT -l;ipchains -I output
-j DENY -l
and then generating a packet storm to that host. Some (most lines at
peak load time) of the log lines were wrapped/jammed due to un overload
on the internal kernel log buffer.
(BTW, if anyone could tell me how to increase that buffer, I'm still
interested)
the consequence is "only" some parts of log lines lost, but the real
trouble was that log analysis tools behaved badly with inconsistent
mostly unusable log data.
Hopefully a proper log policy and a reasonably low load on network
bandwidth will never overload the kernel mode log buffer (I had to use a
pretty heavy load and exhaustive log policy in order to make the problem
happen.
</Linux specific>
The problem here is about missing some of the syslog datagrams. May be
there is not such a format inconsistency problem (datagrams lost may not
overlap log lines boundaries ?), but missing a log line for a specific
event could make some pattern maching tools behave pretty badly in
certain cases.
More precisely, every pattern of an attack that will be diagnosed
differently depending on the existence of one single line will fail if
such a problem occurs. Repetitive DoS attack will still be detected
properly, but more subtle known attack patterns will not, and yet an
original attack pattern could be very difficult to understand and track
down.
Paul Boyer.
> --- Shafik Yaghmour <shafik@ACM.POLY.EDU> wrote:
> > So if you have a high system load it is okay to have some of the
> > syslog messages lost? Hmm, I dunno, IMHO it is never okay, I mean why
> > should you open up the opportunity at all. You know, security based on
> > something being "not so prone to failure" doesn't exactly make me feel
> > warm and cozy.
The weather in Paris is pretty cold, too ;-)
