[7026] in bugtraq
Re: security hole in mailx
daemon@ATHENA.MIT.EDU (Ben Collins)
Thu Jun 25 14:09:01 1998
Date: Thu, 25 Jun 1998 05:58:24 -0500
Reply-To: Ben Collins <bmc@VISI.NET>
From: Ben Collins <bmc@VISI.NET>
X-To: Alvaro Martinez Echevarria <alvaro@LANDER.ES>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.LNX.3.96.980625061051.12634A-300000@leon.lander.es>
I tried this on Solaris 2.6 with no segmantation fault, so I assume the=
re
is an unexloitable version of 5.0:
$ HOME=3D`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=3D`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=3D`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=EDnez Echevarr=EDa
> LANDER SISTEMAS
> P=BA Castellana, 121
> 28046 Madrid, SPAIN
>
>
