Date: Mon, 19 Jul 1999 09:20:44 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Seth <seth@freebie.dp.ny.frb.org> Cc: security@freebsd.org Subject: Re: Shared memory DoS's (fwd) Message-ID: <Pine.BSF.3.96.990719091429.9562A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.10.9907190907040.36787-100000@freebie.dp.ny.frb.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Jul 1999, Seth wrote: > Anyone following this bugtraq thread? Following it, but don't have much to say. :-) Matt Dillon has confirmed that the memory system doesn't impose resource limits on mmaping and other shared memory IPC (this was actually raised on -hackers a few months ago, I think), and that it probably should. I haven't tried the posted sample code, but generally speaking if memory resources become low, the guilty process is terminated when the vm system discoveres it doesn't have the pages to back the request, so I suspect the same thing happens, although the system could get quite sluggish in the process. I'd like to see a first-hand report from someone who has a spare crash machine to give it a try, however. :-) Since this is a DOS and not a root exploit, my feeling is that it should be fixed, but it isn't particularly urgent, although it should be addressed. Matt's overall VM quota per-uid seems to make sense to me, but sounds like something he should be implementing, not me, given my somewhat pathetic knowledge of the VM system :-). > Date: Sat, 17 Jul 1999 14:47:23 -0500 > From: Mike Perry <mikepery@MIKEPERY.LINUXOS.ORG> > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: Re: Shared memory DoS's > > 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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990719091429.9562A-100000>