>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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:59:30 PDT