[7024] in bugtraq

home help back first fref pref prev next nref lref last post

Re: security hole in mailx

daemon@ATHENA.MIT.EDU (Casper Dik)
Thu Jun 25 13:13:01 1998

Date: 	Thu, 25 Jun 1998 12:05:58 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  Your message of "Thu, 25 Jun 1998 06:19:29 +0200." 
              <Pine.LNX.3.96.980625061051.12634A-300000@leon.lander.es>

>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

home help back first fref pref prev next nref lref last post