Re: Digital Unix 4.0 exploitable buffer overflows

[lamontg () RAVEN GENOME WASHINGTON EDU (Lamont Granquist)]

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 <bobv () dcs rhbnc ac uk>
Subject: SUMMARY: Why are MH utilities setuid?
To: alpha-osf-managers () ornl gov

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                       lamontg () 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 () raven genome washington edu | pgp -fka