Re: Hijacking Apache 2 via mod_perl

From: Matthew Wakeling (mnw21-bugtraq_at_jumpleads.com)
Date: 01/23/04

  • Next message: rsh_at_idirect.com: "Re: Major hack attack on the U.S. Senate" 
    Date: Fri, 23 Jan 2004 21:39:34 +0000 (GMT)
To: Steve G <linux_4ever@yahoo.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
  • Next message: rsh_at_idirect.com: "Re: Major hack attack on the U.S. Senate"
    Loading