OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1998: Re: security hole in mailx

Re: security hole in mailx

Casper Dik (casperHOLLAND.SUN.COM)
Thu, 25 Jun 1998 12:05:58 +0200

>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