Bugtraq mailing list archives
Re: Shared memory DoS's
From: nico () ROUTED NET (Nicolas V. Chernyy)
Date: Thu, 15 Jul 1999 22:28:02 -0500
On most bsd systems including my FreeBSD machine you can set such limits with ulimits a-la /etc/login.conf and login classess. I think that people who pretend to run large systems on small hardware like myself should invest time in setting up login classess. My current configuration has proven to be effective against fork bombs and memory related DoSes such as this one. -Nick Chernyy, BOFH-wannabee 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 ------------------------------------------------------------------------ vmfuxx0r.cName: vmfuxx0r.c Type: Plain Text (text/plain) login.patchName: login.patch Type: Plain Text (text/plain)
Current thread:
- Shared memory DoS's Mike Perry (Jul 14)
- Re: Shared memory DoS's Dustin Marquess (Jul 15)
- Re: Shared memory DoS's (Redhat retraction) Mike Perry (Jul 15)
- Re: Shared memory DoS's (Redhat retraction) Jim Dennis (Jul 19)
- Linux +ipchains+ ping -R Andrej Todosic (Jul 22)
- Re: Linux +ipchains+ ping -R Scott (Jul 23)
- Update to Microsoft Security Bulletin (MS99-025) aleph1 () UNDERGROUND ORG (Jul 23)
- Re: Shared memory DoS's (Redhat retraction) Wietse Venema (Jul 22)
- Alert: RDS IIS vulnerability/fix .rain.forest.puppy. (Jul 23)
- Re: Shared memory DoS's Dick St.Peters (Jul 15)
- Re: Shared memory DoS's Nicolas V. Chernyy (Jul 15)
- Re: Shared memory DoS's Mike Perry (Jul 17)
- Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 David Luyer (Jul 16)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Ollivier Robert (Jul 19)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Matt Dunn (Jul 22)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Daniele Orlandi (Jul 24)
- Re: Shared memory DoS's Glynn Clements (Jul 16)
- Re: Shared memory DoS's Mike Perry (Jul 16)
- Re: Shared memory DoS's Howard Kaye (Jul 19)
- Samba 2.0.5 security fixes Andrew Tridgell (Jul 20)
- Re: Shared memory DoS's Richard Shetron (Jul 20)
(Thread continues...)