RE: [Full-Disclosure] Re: Buffer Overflow in ActivePerl ?

[Bill Royds]

C:\Documents and Settings\Bill>Perl -v

This is perl, v5.8.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2002, Larry Wall

Binary build 802 provided by ActiveState Corp. http://www.ActiveState.com
Built 00:54:02 Nov 8 2002


Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.


C:\Documents and Settings\Bill>perl -e "$a="A" x 256; system($a)"


===========crashes with instruction at ox78f... Referenced memory at
0x41414141
so it is a stqack overflow. Haven't tried to exploit it yet.


-----Original Message-----
From: full-disclosure-admin@lists.netsys.com
[mailto:full-disclosure-admin@lists.netsys.com] On Behalf Of
rich.sf@lclogic.com
Sent: May 17, 2004 8:59 PM
To: Oliver@greyhat.de
Cc: full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
Subject: [Full-Disclosure] Re: Buffer Overflow in ActivePerl ?

Reproduced with 5.6.1/win95.

On Mon, 17 May 2004, Oliver@greyhat.de wrote:

> Date: Mon, 17 May 2004 22:23:56 +0200
> From: "Oliver@greyhat.de" <Oliver@greyhat.de>
> To: full-disclosure@lists.netsys.com
> Cc: bugtraq@securityfocus.com
> Subject: Buffer Overflow in ActivePerl ?
>
> hi folks,
>
> i played around with ActiveState's ActivePerl for Win32, and crashed
> Perl.exe with the following command:
>
> perl -e "$a="A" x 256; system($a)"
>
> I wonder if this bug isnt known?!? Because system() is a very common
> command....
> Can anybody reproduce this?
>
> I put together a little advisory on my website, including version
> information and a debugger output (Drwatson):
>
> http://www.oliverkarow.de/research/ActivePerlSystemBOF.txt
>
>
> PS: Due to travel activity, i will not be able to respond to mails
> within the next 8 days!
>
> Regards,
>
> Oliver
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[rich.sf@lclogic.com]

Reproduced with 5.6.1/win95.

On Mon, 17 May 2004, Oliver@greyhat.de wrote:

> Date: Mon, 17 May 2004 22:23:56 +0200
> From: "Oliver@greyhat.de" <Oliver@greyhat.de>
> To: full-disclosure@lists.netsys.com
> Cc: bugtraq@securityfocus.com
> Subject: Buffer Overflow in ActivePerl ?
>
> hi folks,
>
> i played around with ActiveState's ActivePerl for Win32, and crashed
> Perl.exe with the following command:
>
> perl -e "$a="A" x 256; system($a)"
>
> I wonder if this bug isnt known?!? Because system() is a very common
> command....
> Can anybody reproduce this?
>
> I put together a little advisory on my website, including version
> information and a debugger output (Drwatson):
>
> http://www.oliverkarow.de/research/ActivePerlSystemBOF.txt
>
>
> PS: Due to travel activity, i will not be able to respond to mails
> within the next 8 days!
>
> Regards,
>
> Oliver
>

[Nick FitzGerald]

"Oliver@greyhat.de" <Oliver@greyhat.de> wrote:

> i played around with ActiveState's ActivePerl for Win32, and crashed
> Perl.exe with the following command:
>
> perl -e "$a="A" x 256; system($a)"

Ditto -- "v5.8.0 built for MSWin32-x86-multi-thread" on Win2K SP4 plus
all but last week's security patch:

perl -e "$a="A" x 256; system($a)"

perl.exe - Application error

Unhandled instruction at "0x77fcc83d" referenced memory at
"0x00657865. The memory could not be "written".

Also, it is likely exploitable -- push up the number of A's a bit:

C:\>perl -e "$a="A" x 259; system($a)"

perl.exe - Application error

Unhandled instruction at "0x77fcc83d" referenced memory at
"0x65004141. The memory could not be "written".

and we seem to get control of EIP. Coincidence? Try yet two more:

C:\>perl -e "$a="A" x 261; system($a)"

perl.exe - Application error

Unhandled instruction at "0x77fcc83d" referenced memory at
"0x41414141. The memory could not be "written".

Looks like full control of EIP...

However, there is not likely to be a privilege escalation here unless
perhaps a script processor on a web server can be cajoled into doing
something with this?? (Not at all familiar with the innards of Windows
web servers and their relationship to their CGI, etc processors...)


--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

In-Reply-To: <40AAB885.10935.31071242@localhost>

>Looks like full control of EIP...
>
>However, there is not likely to be a privilege escalation here unless
>perhaps a script processor on a web server can be cajoled into doing
>something with this?? (Not at all familiar with the innards of Windows
>web servers and their relationship to their CGI, etc processors...)
>
>
>--
>Nick FitzGerald
>Computer Virus Consulting Ltd.
>Ph/FAX: +64 3 3529854
>
>

Unethical intruders don't always require "privilege escalation", executing code on another system is enough, depending on the goal.

Networks where say developers are sharing source tree's and the like, placing a hostile piece of code in the central store will allow remote code execution on the developer nodes.

Other registers other than EIP can be written, depending on the version, however we need not rely on EIP to allow for a buffer overflow exploit, we don't "need" to overwrite any register in fact to execute code, only to cause a buffer overflow >;]

cheers

[Drew Copley]

=20

> -----Original Message-----
> From: noderat@hotmail.com [mailto:noderat@hotmail.com]=20
> Sent: Tuesday, May 18, 2004 9:11 PM
> To: bugtraq@securityfocus.com
> Subject: Re: Buffer Overflow in ActivePerl ?
>=20
> In-Reply-To: <40AAB885.10935.31071242@localhost>
>=20
> >Looks like full control of EIP...
>=20
> >
>=20
> >However, there is not likely to be a privilege escalation=20
> here unless=20
>=20
> >perhaps a script processor on a web server can be cajoled into doing=20
>=20
> >something with this?? (Not at all familiar with the innards=20
> of Windows=20
>=20
> >web servers and their relationship to their CGI, etc processors...)
>=20
> >
>=20
> >
>=20
> >--=20
>=20
> >Nick FitzGerald
>=20
> >Computer Virus Consulting Ltd.
>=20
> >Ph/FAX: +64 3 3529854
>=20
> >
>=20
> >
>=20
>=20
>=20
> Unethical intruders don't always require "privilege=20
> escalation", executing code on another system is enough,=20
> depending on the goal.
>=20
>=20
>=20
> Networks where say developers are sharing source tree's and=20
> the like, placing a hostile piece of code in the central=20
> store will allow remote code execution on the developer nodes.

The beauty of holes in perl itself is the possibility that
it could affect a widerange of perl scripts out there sleeping on
people's webservers, though.

I would guess, however, a function named "system" is not likely
used by very many scripts and probably has some serious other issues.

.... looking ...

http://iis1.cps.unizar.es/Oreilly/perl/learn32/ch14_01.htm#ch14-23962

example given:
system("dir >this_dir") && die "cannot create this_dir";

....

Yeah, so if you have control over the parameter of "system" call
in perl on a webserver, you have complete access, anyway.

People should look at the other functions in there. This is interesting
as it may be that there are more easily accessible functions in there
which may be exploitable.=20

With an overflow attack, or similiar, you would bypass - likely - most
mechanisms designed to filter out your typical injection attacks which
generally rely on logical operators and the such -- not just too long
of variables or otherwise improper but valid variables.

>=20
>=20
>=20
> Other registers other than EIP can be written, depending on=20
> the version, however we need not rely on EIP to allow for a=20
> buffer overflow exploit, we don't "need" to overwrite any=20
> register in fact to execute code, only to cause a buffer overflow >;]
>=20
>=20
>=20
> cheers
>=20
>=20

[Josh Tolley]

Also reproduced in perl v5.8.0 build 806 on WinXP Pro.

rich.sf@lclogic.com wrote:

>Reproduced with 5.6.1/win95.
>
>On Mon, 17 May 2004, Oliver@greyhat.de wrote:
>
>
>
>>Date: Mon, 17 May 2004 22:23:56 +0200
>>From: "Oliver@greyhat.de" <Oliver@greyhat.de>
>>To: full-disclosure@lists.netsys.com
>>Cc: bugtraq@securityfocus.com
>>Subject: Buffer Overflow in ActivePerl ?
>>
>>hi folks,
>>
>>i played around with ActiveState's ActivePerl for Win32, and crashed
>>Perl.exe with the following command:
>>
>>perl -e "$a="A" x 256; system($a)"
>>
>>I wonder if this bug isnt known?!? Because system() is a very common
>>command....
>>Can anybody reproduce this?
>>
>>I put together a little advisory on my website, including version
>>information and a debugger output (Drwatson):
>>
>> http://www.oliverkarow.de/research/ActivePerlSystemBOF.txt
>>
>>
>>PS: Due to travel activity, i will not be able to respond to mails
>>within the next 8 days!
>>
>>Regards,
>>
>>Oliver
>>
>>
>>

[David Cantrell]

[CCed to activestate in case they were unaware of the discussion on
bugtraq - activestate people, see the archives]

On Tue, May 18, 2004 at 03:23:16PM -0700, Drew Copley wrote:

> The beauty of holes in perl itself is the possibility that
> it could affect a widerange of perl scripts out there sleeping on
> people's webservers, though.

This isn't really a hole in perl itself, but in the particular build of
perl compiled and shipped by one particular vendor. I can not replicate
this on OpenBSD, Debian Linux, or Solaris. Nor can I replicate it using
the version of perl supplied with Cygwin.

I'd be interested to hear if a similar bug exists in Activestate's build
of perl for Linux and Solaris, which I didn't try.

In any case, if an attacker can inject his choice of data into a
system() function, then all bets are off so this is not something that
the users should worry too much about.

--
David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david

<davorg> clowns are scary
<gbjk> I concur. It's their motivation that worries me.
-- in #london.pm

[David Ahmad]

On Wed, May 19, 2004 at 10:00:15AM +0100, David Cantrell wrote:
> [CCed to activestate in case they were unaware of the discussion on
> bugtraq - activestate people, see the archives]
>
> This isn't really a hole in perl itself, but in the particular build of
> perl compiled and shipped by one particular vendor. I can not replicate
> this on OpenBSD, Debian Linux, or Solaris. Nor can I replicate it using
> the version of perl supplied with Cygwin.

Right, just like any system-dependent (i.e. requiring syscalls)
operation.

While the interface is the same, system() is going to be implemented
differently on different platforms. Obviously so, since there is
no Windows fork() system call, no exec and no "/bin/sh".
It is up to the developers porting Perl to Win32 (ActiveState) to
implement this (and/or the more primitive operations it depends on)
such that the interface remains consistent. It seems they have
an overflow somewhere in the native code that system() is built on,
either in the implementation of the function itself (if that is
how it was done) or in the platform-dependent implementation of
"Create new process" and "Execute command-line" operations and
whatever else at the system-level that system() depends on, if
system() itself was written in Perl.

> I'd be interested to hear if a similar bug exists in Activestate's build
> of perl for Linux and Solaris, which I didn't try.
>
> In any case, if an attacker can inject his choice of data into a
> system() function, then all bets are off so this is not something that
> the users should worry too much about.

I disagree here. I can see a scenario where externally supplied
data is included in a command-line string, except that it has
been checked for shell metacharacters beforehand. In that
situation, the overflow may yet be exploitable while
traditional system() "injection" attacks are not.

> --
> David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david
>
> <davorg> clowns are scary
> <gbjk> I concur. It's their motivation that worries me.
> -- in #london.pm

--
David Mirza Ahmad
Symantec

PGP: 0x26005712
8D 9A B1 33 82 3D B3 D0 40 EB AB F0 1E 67 C6 1A 26 00 57 12