bugtraq - Re[2]: Hijacking Apache 2 via mod

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 22 Jan 2004 20:37:00 +0300
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: Ben Laurie <ben@...roup.co.uk>
Cc: Steve Grubb <linux_4ever@...oo.com>, bugtraq@...urityfocus.com,
	httpd security <security@...pd.apache.org>
Subject: Re[2]: Hijacking Apache 2 via mod_perl

Dear Ben Laurie,

--Thursday, January 22, 2004, 6:53:01 PM, you wrote to linux_4ever@...oo.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
Когда птичка погибает от обжорства, ее нанизывают на вертел.  (Лем)