Re: Shared memory DoS's

[mikepery () MIKEPERY LINUXOS ORG (Mike Perry)]

Thus spake Glynn Clements (glynn () sensei co uk):
> >   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