Date: Thu, 25 Jun 1998 14:35:59 -0400
From: Seth McGann <[email protected]>
To: [email protected]Subject: Re: security hole in mailx
At 06:19 6/25/98 +0200, you wrote:
[snip]
>Here we go. By the way, although in Linux 2000 "A"s are enough,
>in Solaris you'll need more (10000 worked for me). I've verified
>that Debian GNU/Linux (package mailx-8.1.1-9 and previous) is
>vulnerable. Solaris 5.5.1 and 5.6 (mailx 5.0) also seem vulnerable
>after a couple of quick tests, but I haven't been able to
>check the return address due to lack of a root access to any
>Solaris, so I'm not 100% sure.
[snip]
I assume you cannot retrieve the return address because the core dump
cannot be read by you, since mailx is sgid. There are couple ways around
this. First, copy the mailx binary to your home directory and run it with
the necessary amount of garbage and examine the core dump. Some overflows
will not dump core so you need to use a different technique:
1. gdb mailx
2. run perl -e '.......'
3. Examine the results as the program dies and gdb catches the signal.
Obviously, this wont work with a program that bails before the overflow
because it sees it doesn't have enough privilege.
Another useful technique when examining programs that neither dump core,
and cannot be started from the command line (well, they probably could, but
this way is easier) is the process attachment feature of gdb. Services
started out of inetd can be easily debugged using this method:
1. In terminal 1 start up the service by connecting to it (I prefer
netcat, but whatever).
2. In terminal 2, do a ps to retrieve the pid of the offending service.
3. gdb /path/to/bad/service pidofservice.
4. gdb will break the process on attachment so give it a 'continue' to
keep going.
5. Do the deed in terminal 1.
6. Watch the fireworks in terminal 2, and see exactly what happened.
Since you can only attach to process you own, you'd have to be root to do
this with inetd type services.
On another note, I think it would be a great display of civil disobedience
to continue publishing this list if the WIPO bill is passed.
Seth M. McGann / [email protected] "Security is making it
http://www.wpi.edu/~smm to the bathroom in time."
KeyID: 2048/1024/E2501C80
Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80
