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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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