[33198] in bugtraq
Re[2]: Hijacking Apache 2 via mod_perl
daemon@ATHENA.MIT.EDU (3APA3A)
Thu Jan 22 16:26:57 2004
Date: Thu, 22 Jan 2004 20:37:00 +0300
From: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Reply-To: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Message-ID: <60705914.20040122203700@SECURITY.NNOV.RU>
To: Ben Laurie <ben@algroup.co.uk>
Cc: Steve Grubb <linux_4ever@yahoo.com>, bugtraq@securityfocus.com,
httpd security <security@httpd.apache.org>
In-Reply-To: <400FF1DD.7050504@algroup.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
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.
--
~/ZARAZA
Когда птичка погибает от обжорства, ее нанизывают на вертел. (Лем)
