mailing list archives
Re: Shared memory DoS's
From: jailbird () ALCATRAZ FDF NET (Dustin Marquess)
Date: Thu, 15 Jul 1999 17:13:27 -0500
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
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
Then, the following passage from shmctl(2) under Linux caught my eye:
"The user must ensure that a segment is eventually destroyed; otherwise its
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
Now the end result is no different than a simple fork or malloc bomb, but
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,
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
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
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
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
sample /etc/limits file:
# Limit the user guest to 5 minutes CPU time and 8 procs, 5Mb address space
# 60 min's CPU time, 30 procs, 15Mb data, 50 megs total address space, 5 megs
# stack, 15 megs of RSS.
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.
Proud user of both PGP 2.6.3i and GNU Privacy guard.
Considering overthrowing any governments? Count me in!