Bugtraq mailing list archives
Re: Shared memory DoS's
From: mikepery () MIKEPERY LINUXOS ORG (Mike Perry)
Date: Sat, 17 Jul 1999 14:47:23 -0500
If you had read the report closely you would see that FreeBSD has no limits to set. The shells can set limits, but none of them effect mmap or shmget. Try actually running the exploit (with the __FUXX0R_SYSV__ option for best results.. See previous mails), you'll be pleasantly surprised :) If you still don't believe me, check sys/vm/vm_mmap.c and see for yourself. The only two limits checked are RLIMIT_MEMLOCK (a limit on the amout of memory a user can mark as non-swappable), and RLIMIT_STACK, a limit on how much stack space mmap can use if it is configured to mmap memory into the stack region for some reason (doesn't sound like the default, and when you want to map into stack, you have to specifically request it on BSD). The same goes for the Linux shells. They have limits, but none of them set RLIMIT_AS. You have to use pam, or Sys V init, or my patch. Lshell does not set the RLIMIT_AS limit either, you have to apply my patch to it (my path to login.c was actually based on lshell, and says so if you read it). After more research, it seems that System V implements RLIMIT_VMEM to stop people from exploiting this problem, but apparently when BSD implemented the Sys V IPC, they neglected to add an appropriate RLIMIT. P.S. For people who have reported to me that using small segments to map causes the program to segfault, this is because the default attack is mmap (see previous mails), and you can do an infinite number of private mmapings. I use an array of pointers to keep track of the memory to free it when the __REALLY_FUXX0R__ option isn't set. So I overrun my own buffer. The buffer size is 2 times the limit for SysV IPC shares for processes, so the buffer will not be overrun with that attack. (I was not about to realloc the buffer dynamically for mmap.. just use a larger buffer size to eat up more than your total ram using only SHMSEG*2 segments). Thus spake Nicolas V. Chernyy (nico () ROUTED NET):
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)
-- 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
Current thread:
- Re: Shared memory DoS's, (continued)
- 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)
- Delegate creates directories writable for anyone Olaf Seibert (Jul 21)
(Thread continues...)