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 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:30:56 PDT