Thus spake Glynn Clements (glynnat_private): > > 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) > > mmap() is potentially less serious as the memory will be released if > the processes are killed. Will it be released if you can rig two processes to share memory together, and only one faults the pages? Right now I'm only doing anonymous mapping through /dev/zero in the attack. Setting up two proccesses together was too much work for the initial exploit (not to mention you'd need as much or more disk space to waste as you have ram), and I have other things to get done now as well. Plus it's my birthday :) P.S. Right now, people who are testing this exploit, the default attack is __FUXX0R_MMAP__. I posted the wrong file to the list. I meant to post one that had the default attack of __FUXX0R_SYSV__, and with __REALLY_FUXX0R__ undefined (so the prog wouldn't actually page fault and kill your system, if you just wanted to see if limits would kick in). Please change these before running the exploit. System V IPC is where the real kernel crusher is. I have some preliminary reports, and it seems that OpenBSD 2.5-current (Jul 3) is vulnerable. The place to check if you're vulnerable is sys/resource.h, or if you're BSD and have kernel source, checking sys/vm/vm_mmap.c for RLIMIT other than STACK should let you know. The proper way to fix this is to have a seperate limit for address space or virtual memory. Solaris has both (probably since their malloc uses both brk and mmap, and the virtual memory limit is for stopping malloc bombs). <flamebait> The Linux vm code is in mm/mmap.c and ipc.c/shm.c, if you BSD floks are looking for a way to patch your systems in a hurry. </flamebait> (Heh. Just kidding about this, I'm well aware that you guys can have a better fix for your kernel faster than I could, that's why I didn't post one - esp since I couldn't even test to see if my fixed compiled, let alone booted. One of these days I'm gonna start dual booting ;) -- 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:52:31 PDT