I tried this on Solaris 2.6 with no segmantation fault, so I assume there is an unexloitable version of 5.0: $ HOME=`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=`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=`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ínez Echevarría > LANDER SISTEMAS > Pº Castellana, 121 > 28046 Madrid, SPAIN > >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:59:32 PDT