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
| ||
|
Date: Thu, 22 Jan 2004 18:42:28 +0100 From: André Malo <nd@...lig.de> To: 3APA3A <3APA3A@...URITY.NNOV.RU> Cc: Ben Laurie <ben@...roup.co.uk>, Steve Grubb <linux_4ever@...oo.com>, bugtraq@...urityfocus.com, httpd security <security@...pd.apache.org> Subject: Re: Hijacking Apache 2 via mod_perl * 3APA3A <3APA3A@...URITY.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
Powered by blists - more mailing lists