[33193] in bugtraq
Re: Hijacking Apache 2 via mod_perl
daemon@ATHENA.MIT.EDU (Ben Laurie)
Thu Jan 22 15:36:01 2004
Message-ID: <401018E7.8030408@algroup.co.uk>
Date: Thu, 22 Jan 2004 18:39:35 +0000
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Cc: Steve Grubb <linux_4ever@yahoo.com>, bugtraq@securityfocus.com,
httpd security <security@httpd.apache.org>
In-Reply-To: <60705914.20040122203700@SECURITY.NNOV.RU>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
3APA3A wrote:
> Dear Ben Laurie,
>
> --Thursday, January 22, 2004, 6:53:01 PM, you wrote to linux_4ever@yahoo.com:
>
> BL> This is not a leak - mod_perl is a module that is compiled into Apache,
> BL> and hence has access to all its resources (including memory). If you
> BL> want to run untrusted Perl, then don't use mod_perl.
>
> You're right: mod_perl is inside apache memory space and can access any
> descriptor, so it's impossible to blame apache descriptor is leaked. But
> you're wrong. mod_perl has access to memory, not perl script. At least,
> it's possible to store descriptors table and implement check for
> descriptor in every perl file/socket function inside mod_perl (and
> mod_php and mod_something) and only allow access to std descriptors and
> to descriptors open inside same script. The choice is between speed and
> security.
OK, you _might_ be able to do this (but I'll bet you five beers you'll
never make Perl secure enough to avoid circumvention), and I doubt it'd
even noticably impact speed. This is not something Apache can fix, though.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
