[11050] in bugtraq
Re: Shared memory DoS's
daemon@ATHENA.MIT.EDU (Dustin Marquess)
Sat Jul 17 00:02:13 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <4.1.19990715171219.0093c270@purgatory.fdf.net>
Date: Thu, 15 Jul 1999 17:13:27 -0500
Reply-To: Dustin Marquess <jailbird@ALCATRAZ.FDF.NET>
From: Dustin Marquess <jailbird@ALCATRAZ.FDF.NET>
X-To: Mike Perry <mikepery@MIKEPERY.LINUXOS.ORG>,
BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <19990715003612.A18130@mikepery.linuxos.org>
It should be noted that recent versions of the Linux shadow suite support
/etc/limits without patching. I believe Linux-PAM also supports a similar
file.
-Dustin
At 12:36 AM 7/15/99 , Mike Perry wrote:
>Hello, sorry if it's considered poor form to cross post to both bugtraq and a
>development list, but I'm too lazy to fire off two emails.
>
>While fiddling with various IPC mechanisms and reading The Design and
>Implementation of 4.4BSD (What a book!), a few things struch me as potentially
>dangerous. According to the book, when you request a shared memory segment via
>mmap(), the file isn't actually physically in memory until you start to
>trigger page faults and cause the vnode-pager to page in the data from the
>file.
>
>Then, the following passage from shmctl(2) under Linux caught my eye:
>"The user must ensure that a segment is eventually destroyed; otherwise its
> pages
>that were faulted in will remain in memory or swap."
>
>So as it turns out that it is in fact possible to create a DoS condition by
>requesting a truckload of shared mem, then triggering pagefaults in the entire
>shared region.
>
>Now the end result is no different than a simple fork or malloc bomb, but
it is
>considerably harder to prevent on most systems.
>
>This is mainly because:
>
> 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)
> 3. b. The system does not actually allocate shared memory until a page
> fault is triggered (this could be argued to be a feature - Linux,
*BSD)
> a. The system does not watch to make sure you don't share more memory
> than exists. (Linux, Irix, BSD?)
> 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)
>
>I've attached a program that will exploit these conditions using either
>shmget(), mmap(), or by getting malloc to mmap() (those are in order of
>effectivness).
>
>This program should compile on any architecture. SGI Irix is not vulnerable.
>Reading The Design and Implementation of 4.4BSD, it sounds as if the BSDs
>should all be vulnerable. FreeBSD will mmap as much memory as you tell it.
>I haven't tried page faulting the memory, as the system is not mine.
>I'd be very interested to hear about OpenBSD...
>
>Also attached is a patch to util-linux-2.9o login.c (and pathnames.h) that
>provides a means under Linux (should be pretty portable to other OS's) to set
>limits for the address space limit (RLIMIT_AS: the rlimit that controls how
>much data you can actually map into your process). The patch is based on
an old
>program called lshell that set limits by wrapping your shell (I've found that
>wrapping the shell in this way caused all sorts of problems with gdb, for some
>reason).
>
>sample /etc/limits file:
>
># Limit the user guest to 5 minutes CPU time and 8 procs, 5Mb address space
>guest C5P8V5D2
># 60 min's CPU time, 30 procs, 15Mb data, 50 megs total address space, 5 megs
># stack, 15 megs of RSS.
>default C60P30D15V50S5R15
>
>At the very least, I recommend default V<size of physical memory>.
>You can use lowercase letters for the next lowest order of magnitude of units.
>The comment in the patch explains it in further detail.
>
>Note even in this case, a determined user can probably just login a dozen or
>so times and use SysV IPC to steal the system memory. Core wars, anyone? :)
>
>P.S. Util-linux people: I also suspect a small memory leak due to the
>strdup(hostname) provided by Ambrose C. Li.
>
>--
>Mike Perry
>Proud user of both PGP 2.6.3i and GNU Privacy guard.
>Considering overthrowing any governments? Count me in!
>http://mikepery.linuxos.org/keys.html
