mailing list archives
Re: Shared memory DoS's (Redhat retraction)
From: mikepery () MIKEPERY LINUXOS ORG (Mike Perry)
Date: Thu, 15 Jul 1999 17:36:39 -0500
I've been waiting all day for my post to be approved so I could post a
retraction for Redhat Linux and its derivatives. :)
It seems I forgot all about pam. Thanks to Mike Johnson of Redhat for bringing
pam_limits.so to my attention. Any distribution that uses pam can set limits
to prevent this.
However, other distributions like Slackware and the default debian install
still need some method to set the RLIMIT_AS limit. You need to patch login.c
and other methods of authentication (ssh & rlogin, etc), or replace the
appropriate functions in the lshell distribution
(ftp://metalab.unc.edu/pub/Linux/system/admin/login), and wrap your shells
accordingly. I still don't know what to do about dgb in that case. The
alternative is to patch all your system shells and set the rlimits via the
worldwide rc scrips.
I've been told that pam patches do exist for ssh, but I don't have any urls.
FreeBSD is completely vulnerable still. It provides no equalent to the Linux
RLIMIT_AS (RLIMIT_VMEM under Irix), and checks no rlimits for mmap() and
shmget. Still no word on OpenBSD.
P.S. You can undefine __REALLY_FUXX0R__ in vmfuxx0r.c to stop the program from
actually pagefaulting the maped memory, if you want to see OS's for which you
have no kernel source enforce their rlimits for mmap. (the program will also
safely unmap shared memory in this mode).
P.P.S. You can do some very primitive ipc shares manipulation with ipcs(8) and
ipcrm(8). ipcrm only allows you to remove indiviual IPC IDs. the --clean
switch of vmfuxx0r removes all IPC IDs under Linux. (I tried to write
additional functionality for other OS's, but it seems that the SysV IPC calls
aren't very standardized for doing things like that).
Proud user of both PGP 2.6.3i and GNU Privacy guard.
Considering overthrowing any governments? Count me in!