RE: Buffer Overflow in ActivePerl ?

["Drew Copley" <dcopley () eeye com>]

> -----Original Message-----
> From: noderat () hotmail com [mailto:noderat () hotmail com] 
> Sent: Tuesday, May 18, 2004 9:11 PM
> To: bugtraq () securityfocus com
> Subject: Re: Buffer Overflow in ActivePerl ?
>
> 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.

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. 

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.

> 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