[12679] in bugtraq
Re: local users can panic linux kernel (was: SuSE syslogd
daemon@ATHENA.MIT.EDU (Savochkin Andrey Vladimirovich)
Mon Nov 22 15:24:54 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19991120120126.A14799@castle.nmd.msu.ru>
Date: Sat, 20 Nov 1999 12:01:26 +0300
Reply-To: Savochkin Andrey Vladimirovich <saw@MSU.RU>
From: Savochkin Andrey Vladimirovich <saw@MSU.RU>
X-To: Mixter <mixter@NEWYORKOFFICE.COM>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.04.9911190341190.349-200000@aviation.net>; from
"Mixter" on Fri, Nov 19, 1999 at 03:59:00AM
Hello,
I don't understand what all the syslogd discussion is about.
It's absolutely clear that if you start a daemon without any resource limits
being set you risk the whole system if something goes wrong.
So if you want to protect the system from local DoS attacks then resource
limits for all daemons are mandatory.
Resource limits are necessary and they are almost the only thing that can be
done nowadays.
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.
On Fri, Nov 19, 1999 at 03:59:00AM +0100, Mixter wrote:
> The impact of the syslogd Denial Of Service vulnerability seems to
> be bigger than expected. I found that syslog could not be stopped from
> responding by one or a few connections, since it uses select() calls
> to synchronously manage the connections to /dev/log. I made an attempt
> with the attached test code, which makes about 2000 connects to syslog,
> using multiple processes, and my system instantly died with the message:
> 'Kernel panic: can't push onto full stack'
The kernel panic is a completely different issue.
You can reproduce it without syslogd by your own program.
So that is the real problem that should be fixed.
>
> I've been able to reproduce this as non-root user, although it had to
> be done two times to overcome the stronger user resource limits, but
> it worked. This has been tested with linux 2.0.38+syslog1.3 (redhat 5.2).
Best regards
Andrey V.
Savochkin
