Re: security hole in mailx

[casper () HOLLAND SUN COM (Casper Dik)]

> 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.


Let me start of saying that I've filed a bug in the Solaris bug database,
it's #4152234.  (I say this mainly to prevent duplicate filings)


> 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);


It should be noted that homedir itself, at least on Solaris,,
is a char homedir[PATHSIZE] which is copied from the environment.

(This never stops to amaze me; why *copy* the result from getenv()?)

You'd want to fix the overflow of homedir too; looks like there
are a few other overflows as well.

> 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.


I don't particularly care for arguments as "seem exploitable".

The homedir data segment buffer overflow may well be exploitable;
in the Solaris sources, there is at least one other buffer overflow
on the stack.


> 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:


Interesting.

This should work for all shells:


        env HOME=`perl -e 'print "x" x 10000'` ...


Tcsh calls abort().  Weird.

Casper