Re: Hijacking Apache 2 via mod_perl

[Matthew Wakeling <mnw21-bugtraq () jumpleads com>]

On Thu, 22 Jan 2004, Steve G wrote:
> Xinetd, stunnel, and sshd can all run completely untrusted
> applications without leaking their listening descriptor. Why
> can't apache? Its not just mod_perl, mod_php leaks the https
> descriptor, too.

Xinetd, stunnel, and sshd all run completely untrusted applications by
fork()ing, setuid()ing, removing privileged access, and exec()ing an
entirely new chunk of code. You therefore have a clearly-defined barrier
between the privileged system (sshd) and the program it runs (bash, for
example).

The purpose of mod_perl is to run perl code without having to exec a whole
whacking great perl interpreter every time someone accesses a page.
Therefore, the perl is brought inside the apache process-space, and all
that nasty slow fork() and exec() is got rid of.

A consequence of this is security. The apache process MUST be able to get
hold of those priveleged resources again in time for the next request it
has to handle, otherwise it would have to die have have a new apache
process take its place, which would rather defeat the purpose of bringing
perl in-process in the first place. Therefore, if the apache code is able
to regain priveleges, the perl code can too.

If you want to run untrusted code, don't bring it inside a process that
has privileged access.

Matthew

-- 
[About NP-completeness] These are the problems that make efficient use of
the Fairy Godmother.                    -- Computer Science Lecturer