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
