[11053] in bugtraq
Re: Shared memory DoS's
daemon@ATHENA.MIT.EDU (Glynn Clements)
Sat Jul 17 02:02:04 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14223.3866.349048.475776@cerise.sensei.co.uk>
Date: Fri, 16 Jul 1999 11:53:14 +0100
Reply-To: Glynn Clements <glynn@SENSEI.CO.UK>
From: Glynn Clements <glynn@SENSEI.CO.UK>
X-To: Mike Perry <mikepery@MIKEPERY.LINUXOS.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <19990715003612.A18130@mikepery.linuxos.org>
Mike Perry wrote:
> 1. The system does not check rlimits for mmap and shmget (FreeBSD)
> 2. The system never bothers to offer the ability to set the rlimits for
> virtual memory via shells, login process, or otherwise. (Linux)
Some fixes:
The Linux SysVinit (>2.54) uses /etc/initscript (or /sbin/initscript)
to spawn the processes listed in /etc/inittab, so you can set limits
within that (e.g. for the getty processes).
Either wrap in.telnetd or use -L to wrap the login program.
Set limits in the rc.init2 (etc) script for daemons which may execute
user-defined code (e.g. crond, httpd). Similarly for xdm via Xstartup.
You might also want to wrap your MDAs if you are using procmail or
allow program aliases in ~/.forward files.
Some versions of Linux (RedHat?) have a login which allows limits to
be set via a login.defs file.
> 4. With System V IPC, shared memory persists even after the process is
> gone. So even though the kernel may kill the process after it exhausts
> all memory from page faults, there still is 0 memory left for the system.
> I suppose with some trickery you might be able to achieve the same results
> by shared mmap()'ing a few large files between pairs of processes. (All)
mmap() is potentially less serious as the memory will be released if
the processes are killed.
--
Glynn Clements <glynn@sensei.co.uk>
