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 <bobvat_private> Subject: SUMMARY: Why are MH utilities setuid? To: alpha-osf-managersat_private 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 lamontgat_private Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344 Box 352145 / University of Washington / Seattle, WA 98195 PGP pubkey: finger lamontgat_private | pgp -fka
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:31:49 PDT