Re: security hole in mailx

[bmc () VISI NET (Ben Collins)]

I tried this on Solaris 2.6 with no segmantation fault, so I assume there
is an unexloitable version of 5.0:

$ HOME=`perl -e 'print "A"x10000'`
$ mailx
No mail for bmc
$
$ mailx -V
mailx version 5.0 Tue Jul 15 23:42:53 PDT 1997
$


On Thu, 25 Jun 1998, Alvaro Martinez Echevarria wrote:

> Hi there.
>
> I've discovered a rather serious security hole in mailx, the good
> old Berkeley mail program. It's somehow present at least in the
> last versions I've checked (mailx-8.1.1 in Linux, mailx 5.0 in
> Solaris). The bug is an exploitable buffer overflow (using the
> HOME environment variable) that allows any local user to acquire
> the privileges under which the program runs, usually group "mail"
> (on many of the modern versions I've seen, mailx is setgid
> "mail"). So the bug allows you to get "mail" group privileges,
> and this means that at least you can play with other people's
> mail. Although this wouldn't be very nice from you, this
> shouldn't be a big problem for the integrity of the system. But
> there could be a much more serious implication: being able to
> write in /var/spool/mail is usually an open door to the root
> account, for example by using races and such in mail delivery
> programs.
>
> You can check if your particular version of mailx is vulnerable
> through these steps:
>
> $ cp `which mailx` ./mailx
> $ HOME=`perl -e 'print "A"x10000'` ./mailx
> Segmentation fault (core dumped)
> $ gdb ./mailx core
> GNU gdb 4.17
> [...]
> #0  0x41414141 in ?? ()
>
> 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. Redhat Linux mailx has the bug,
> but as they don't install it setgid mail there's no direct
> danger.
>
> About the bug: it is in "fio.c", in the "xname" variable of the
> "expand" function:
>
>   char xname[PATHSIZE];
>   [...]
>   sprintf(xname, "%s%s", homedir, name + 1);
>
> Two attachments are included in this message:
>
> -A patch against mailx-8.1.1 that solves the problem. There
>  are a lot of buffer overflows in the sources of mailx,
>  although only the one I mention seems to be exploitable. The
>  patch is dirty and simple: replace sprintf and strcpy by
>  snprintf and strncpy almost everywhere. I haven't tested it
>  a lot, use it at your own risk.
>
> -An exploit that should work under Linux (at least it does so in
>  Debian). To test: compile it, execute it, and it should give you
>  a shell; check with "id" if you are group "mail". By the way,
>  the program assumes the gid for group mail is 8, as in Debian.
>  Please, use it _JUST_ for testing and educative purposes ;)
>
> I reported the problem a few days ago to Debian, Redhat, Sun, and
> CERT, and I also sent them the patches. So the new versions
> should be on the way or even already released, at least for the
> Linux distributions.
>
> BTW, the person who tested the bug under Solaris (I don't have
> direct access to any Solaris machine) told me that he had a hard
> time:
>
> tcsh$ setenv HOME `perl -e 'print "A"x10000'`
> connection lost
>
> !!! Seems like tcsh doesn't like huge homes like this. Second try:
>
> tsch$ exec sh
> sh$ HOME=`perl -e 'print "A"x10000'`
> sh$ which mailx
> Segmentation Fault (core dumped)
>
> Erm... Seems like Sun is doing a great job with buffer overflows.
> This happened under 5.5.1. I wonder if these have any security
> implication. Anyway, they are not bad as a joke.
>
> Regards.
>
> --
> Alvaro Martínez Echevarría
> LANDER SISTEMAS
> Pº Castellana, 121
> 28046 Madrid, SPAIN