[12711] in bugtraq

home help back first fref pref prev next nref lref last post

Re: local users can panic linux kernel (was: SuSE syslogd

daemon@ATHENA.MIT.EDU (Darren Reed)
Wed Nov 24 02:27:12 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id:  <199911240106.MAA10208@cairo.anu.edu.au>
Date:         Wed, 24 Nov 1999 12:06:05 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To:         saw@MSU.RU
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <19991123125806.A27064@castle.nmd.msu.ru> from "Savochkin Andrey
              Vladimirovich" at Nov 23, 1999 12:58:06 PM

In some mail from Savochkin Andrey Vladimirovich, sie said:
>
> Alan,
>
> On Mon, Nov 22, 1999 at 09:32:38PM +0000, Alan Cox wrote:
> > > It isn't clear for me what can be done to protect the whole system inside
> > > syslogd.  Does anybody knows what SuSE really changed?
> > > Their source package isn't very helpful.
> >
> > There were two notable problems
> >
> > 1.	Syslogd defaulted to stream sockets which means you have resource
> > 	control problems - in fact Dan Bernstein posted some very good stuff
> > 	about that issue about a year ago
> >
> > 2.	The client code decided it would be a good idea to wait - ie do a
> > 	blocking connect. Unfortunate it someone ate all the syslog handles
> >
> > With a datagram system it comes down to losing messages under load.
> > I think that is about as good as you can get.
>
> Thank you for your points.
>
> I think that replacing stream sockets by datagram is a step in a wrong
> direction.  Datagram sockets are not only unreliable by definition.
> Their use makes completely impossible for applications to check if their
> message has been properly logged or no.  Stream sockets allows at least catch
> some cases when the message is lost.

I'd venture to say that this is not true.  The syslog protocol is
unidirectional (sender sends, only) and as such, the sender receives
no indication that messages are ever received or stored.  Using stream
sockets in this environment leads to false beliefs about what happens
at the other end.  The syslog-sec mailling list has been discussing some
of these problems and what would be required to address them.  Just
replacing datagrams with streams is not enough.

[...]
> It's clear that there are some resource control problems with connection
> oriented sockets.  These resource control problems may block logging under
> certain conditions.  But I don't think that these problems are unsolvable.
> As a first step we may consider creating several unix sockets for different
> facilities and some access control.

In an uncontrolled environment, this will do nothing to prevent D.O.S
attacks.  Creating extra sockets just means I've more targets to kill
before completing the mission.

Darren

home help back first fref pref prev next nref lref last post