Bugtraq mailing list archives
More buffer overrun crap -- Solaris 2.5.1 /usr/bin/ps
From: jzbiciak () MICRO TI COM (Joe Zbiciak)
Date: Sat, 10 May 1997 08:15:43 -0500
Hi all, While the last buffer overrun I found in /usr/bin/ps wasn't *obviously* exploitable, I've done some more digging; it may indeed be exploitable. Also, there's another buffer overrun in /usr/bin/ps, related to getopt() This latter buffer overrun is more serious, IMHO, in that it could effect multiple programs -- it's specific to getopt(), not ps. I've not been able to successfully construct an exploit yet; this is partially due to my relative infamiliarity with Sparc assembler and Solaris function calling conventions. Hopefully, somebody can put the pieces together for me from the information below. The first tidbit is related to the original buffer overflow I found, wrt. to all of the "option" receiving arguments. These options are copied into a statically allocated buffer; at position 96 beyond the start of this buffer is the static variable "environ". An additional 864 bytes beyond that is the static variable "optarg", which tells getopt where to place the argument of a commandline switch. Overwriting this to point into someplace interesting, such as the Procedure Linkage Table at 0xef78267c might allow you to install an exploit on a second commandline argument. ie. "ps -u '.....smash optarg....' -g 'exploit code here'" The hitch is that there's a couple other important variables between optarg and environ which may make this non-trivial. Most notable is optind, which is used to index into argv. Trashing that may break the whole works. The second tidbit is an apparent buffer overrun in getopt() itself; it blindly trusts argv[0] and it appears to generate its error message into a local buffer. :-) The basic form of the error message is "%s: -- illegal option %c\n" By passing a large argv[0] (using execl), it is possible to smash the stack. *Note* It appears that a couple local variables to getopt need to be preserved in order to allow getopt to actually return without a segv. The easiest way I was able to determine what values to leave where was using gdb on a non-suid copy of the executable being examined. (This note looks like it's only true if the first "illegal option" is not the last option in an argv[] slot.) This doesn't appear directly exploitable from ps, since it is called from the top-level function (_cg89_used() -- I assume that's main()), which apparently exits using exit(). Other programs which call getopt from a deeper level may be exploitable in this manner. In any case, even if these potential vulnerability aren't as exploitable as I might think, I would feel much safer if Sun were to patch these. Regards, --Joe -- +--------------Joseph Zbiciak--------------+ |- - - - - jzbiciak () micro ti com - - - - -| | - - http://ee1.bradley.edu/~im14u2c/ - - | Not your average "Joe." |- - - - Texas Instruments, Dallas - - - -| +-------#include <std_disclaimer.h>--------+
Current thread:
- Irix: misc Yuri Volobuev (May 07)
- Re: Irix: misc J.A. Gutierrez (May 08)
- Re: Irix: misc Jaechul Choe (May 08)
- SGI Security Advisory 19961203-02-PX - IRIX netprint Program SGI Security Coordinator (May 08)
- Bug Serious problem in NEC SOCKS server Trevor Schroeder (May 09)
- Re: Bug Serious problem in NEC SOCKS server Matt Bush (May 09)
- Windows 95/NT DoS myst (May 09)
- More buffer overrun crap -- Solaris 2.5.1 /usr/bin/ps Joe Zbiciak (May 10)
- Re: More buffer overrun crap -- Solaris 2.5.1 /usr/bin/ps kevin brintnall (May 10)
- Re: Windows 95/NT DoS Albert Siersema (May 10)
- Re: Windows 95/NT DoS DiGennaro (May 10)
- Re: Windows 95/NT DoS Alan Cox (May 11)
- OOB Quick Fix Aleph One (May 10)
- Microsoft PowerPoint Security Fix Aleph One (May 10)
- Re: Windows 95/NT DoS Mikael Brandstrom (May 10)