[33201] in bugtraq
Re: Hijacking Apache 2 via mod_perl
daemon@ATHENA.MIT.EDU (=?ISO-8859-15?Q?Andr=E9?= Malo)
Thu Jan 22 17:07:28 2004
Date: Thu, 22 Jan 2004 18:42:28 +0100
From: =?ISO-8859-15?Q?Andr=E9?= Malo <nd@perlig.de>
To: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Cc: Ben Laurie <ben@algroup.co.uk>, Steve Grubb <linux_4ever@yahoo.com>,
bugtraq@securityfocus.com, httpd security <security@httpd.apache.org>
Message-Id: <20040122184228.00002028.nd@perlig.de>
In-Reply-To: <60705914.20040122203700@SECURITY.NNOV.RU>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
* 3APA3A <3APA3A@SECURITY.NNOV.RU> wrote:
> 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.
Then one just writes a perl extension in C. Who's responsible then?
Who's responsible if you just write a C module which hijacks the
descriptors? Where do you draw the line?
nd
