Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 98369 invoked from network); 31 Jan 2007 10:16:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Jan 2007 10:16:26 -0000 Received: (qmail 9059 invoked by uid 500); 31 Jan 2007 10:16:28 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 9003 invoked by uid 500); 31 Jan 2007 10:16:27 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 8992 invoked by uid 99); 31 Jan 2007 10:16:27 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Jan 2007 02:16:27 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [82.94.235.198] (HELO hyak.bean-it.nl) (82.94.235.198) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Jan 2007 02:16:17 -0800 Received: from [127.0.0.1] (bean-it.xs4all.nl [213.84.27.165]) (authenticated bits=0) by hyak.bean-it.nl (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0VAFkkh030662 for ; Wed, 31 Jan 2007 11:15:49 +0100 Message-ID: <45C06C3B.3020508@adaniels.nl> Date: Wed, 31 Jan 2007 11:15:23 +0100 From: Arnold Daniels User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: State of perchild MPM References: <813368a4a021cb7b517ba62f698618a0@localhost> <20070130213013.15c79129@grimnir> In-Reply-To: <20070130213013.15c79129@grimnir> Content-Type: multipart/alternative; boundary="------------010308010005080608080203" X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hyak.bean-it.nl X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=0.0 required=4.0 tests=BAYES_50,HTML_MESSAGE autolearn=ham version=3.1.7 This is a multi-part message in MIME format. --------------010308010005080608080203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, We run a shared hosting company as well and taken upon the route to patch the linux kernel to allow switching of user of the current process. An apache module allows you to switch the process based on the virtual host. Our current module also implements mass virtual hosting, but any open source module should also work with normal vhost files. We've been discussing this in the PHP internals mailing list and are preparing an open source solution, which can be tested by interested parties. Please read the message below, where security concerns of the PHP are addressed. I'll be sure to post a message on the apache list when the patch is made ready for public viewing. Best regards, Arnold Daniels Javeline (www.javeline.net) ------------------------- Rik Arends schreef: > Hi Andi, > > I'm Rik Arends, i co-wrote the kernel patch + apache module for > in-process user switching. > After reading your concerns i might shed some light on these issues. > > First of all, i know that there are some possible security holes with > this system. > One of the biggest problems i could see is triggering a bufferoverflow > in mod_php, so the user can get its own assembler code to run. > Then by knowing how to do the kernel calls, he could, theoretically > switch the user of the process back to www-data, after which he could > switch to > any 'shared hosting user' (not just any user) in the system to access > their shared hosting files. > The complexity of this hack, plus that your apaches will be > segfaulting continously while a person is trying this might not make > it too plausible to happen. > Second, the main system would not be at risk, just some of the shared > hosting users-files that might be accessed. In 99.99% of the cases, > there really is not all that much to steal and the amount of effort to > actually hack this is pretty huge and requires exploitation of a > hardcore hole in an in-process scripting engine (mod_php for > instance), plus the knowledge on how to trigger the right kernel > calls, and the userID's to switch to (which, unless the user somehow > gained shell access to his targets directory he has no clue about) > > The same way i think we can approach the, the 'resources that are > still open from other users' hole, if it might be there. I expect > mod_php or other modules to do proper cleanup of their handles or else > they would be leaking a lot in an apache process thats being reused. > This is not a new problem, and also a very very difficult one to > succesfully exploit. > Say we have 256 apache processes with user switching. You are > targetting site X running on the 'same machine'. Then you'd have to > poll continously and hope you are served by an apache process that > also served the other site AND know which resources to access, and how > to do that. Please note that you can only use the resource leak bug > when you are using an in-process scripting engine so you cant just go > poke around your memory. This same 'bug' if you will is also there in > shared hosting structures with reused apache processes that don't do > user switching at all. Again the risk of this exploit actually being > used seems well, remote. Add to this the fact that in shared hosting > environments, nobody runs any security critical applications such as > full creditcard payment systems. For that people employ their own > server with SSL and certificates. That is just beyond the scale of > shared hosting. > > I hope i might have lessened your concerns. I think the security risk > our patch poses is mostly theoretical, have a very difficult exploit > route and in almost all cases have a 0 to almost nil payoff. Its much > much simpler to try to hack the other persons site via bugs in forms > or other installed applications. > > Regards, > > Rik Arends > >> >> >> -------- Originele bericht -------- >> Onderwerp: RE: [PHP-DEV] Comments on PHP security >> Datum: Thu, 18 Jan 2007 14:14:17 -0800 >> Van: Andi Gutmans >> Aan: 'Arnold Daniels' , >> >> >> >> I haven't seen the patch yet but my concern would be with resources >> which have already been opened. Unless you guys clean that up in >> between requests it can be very dangerous as I doubt Linux >> re-verify's permissions when those are accessed. In any case, I'd be >> happy to review and might be completely wrong... >> > ------------------------- Nick Kew schreef: > On Mon, 29 Jan 2007 20:31:40 -0600 > wrote: > > >> I have gotten the impression this may be a sore subject for the list >> based on searching through the archives, but I do not intend to work >> anyone up. I have been trying to find a solution to the problem of >> shared hosting with a dynamic language such as PHP. I found the old >> perchild MPM and it appears it is not being maintained or there was >> possibly a design problem. I would like to know two things. >> >> 1. Is there a mechanism (other than suexec) that allows functionality >> similar to perchild, that will allow a uid to be assigned on a per >> request basis? >> > > There are several third-party solutions: google for metux, peruser, > mod_ruid, and fastcgi. > > >> 2. If there is, do the developers need help with it? I can write C >> and I am willing to help out with this. If there is not, Would >> anyone from the Apache team be interested in working with me so I may >> write such functionality, maybe for a future version of Apache? >> > > Patches welcome. > > Bear in mind that perchild was threaded, and therefore never > likely to be suitable for php. > > --------------010308010005080608080203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

We run a shared hosting company as well and taken upon the route to patch the linux kernel to allow switching of user of the current process. An apache module allows you to switch the process based on the virtual host. Our current module also implements mass virtual hosting, but any open source module should also work with normal vhost files.

We've been discussing this in the PHP internals mailing list and are preparing an open source solution, which can be tested by interested parties. Please read the message below, where security concerns of the PHP are addressed. I'll be sure to post a message on the apache list when the patch is made ready for public viewing.

Best regards,

Arnold Daniels
Javeline (www.javeline.net)

-------------------------

Rik Arends schreef:
Hi Andi,

I'm Rik Arends, i co-wrote the kernel patch + apache module for in-process user switching.
After reading your concerns i might shed some light on these issues.

First of all, i know that there are some possible security holes with this system.
One of the biggest problems i could see is triggering a bufferoverflow in mod_php, so the user can get its own assembler code to run.
Then by knowing how to do the kernel calls, he could, theoretically switch the user of the process back to www-data, after which he could switch to
any 'shared hosting user' (not just any user) in the system to access their shared hosting files.
The complexity of this hack, plus that your apaches will be segfaulting continously while a person is trying this might not make it too plausible to happen.
Second, the main system would not be at risk, just some of the shared hosting users-files that might be accessed. In 99.99% of the cases, there really is not all that much to steal and the amount of effort to actually hack this is pretty huge and requires exploitation of a hardcore hole in an in-process scripting engine (mod_php for instance), plus the knowledge on how to trigger the right kernel calls, and the userID's to switch to (which, unless the user somehow gained shell access to his targets directory he has no clue about)

The same way i think we can approach the, the 'resources that are still open from other users' hole, if it might be there. I expect mod_php or other modules to do proper cleanup of their handles or else they would be leaking a lot in an apache process thats being reused. This is not a new problem, and also a very very difficult one to succesfully exploit.
Say we have 256 apache processes with user switching. You are targetting site X running on the 'same machine'. Then you'd have to poll continously and hope you are served by an apache process that also served the other site AND know which resources to access, and how to do that. Please note that you can only use the resource leak bug when you are using an in-process scripting engine so you cant just go poke around your memory. This same 'bug' if you will is also there in shared hosting structures with reused apache processes that don't do user switching at all. Again the risk of this exploit actually being used seems well, remote. Add to this the fact that in shared hosting environments, nobody runs any security critical applications such as full creditcard payment systems. For that people employ their own server with SSL and certificates. That is just beyond the scale of shared hosting.

I hope i might have lessened your concerns. I think the security risk our patch poses is mostly theoretical, have a very difficult exploit route and in almost all cases have a 0 to almost nil payoff. Its much  much simpler to try to hack the other persons site via bugs in forms or other installed applications.

Regards,

Rik Arends



-------- Originele bericht --------
Onderwerp:     RE: [PHP-DEV] Comments on PHP security
Datum:     Thu, 18 Jan 2007 14:14:17 -0800
Van:     Andi Gutmans <andi@zend.com>
Aan:     'Arnold Daniels' <info@adaniels.nl>, <internals@lists.php.net>



I haven't seen the patch yet but my concern would be with resources which have already been opened. Unless you guys clean that up in
between requests it can be very dangerous as I doubt Linux re-verify's permissions when those are accessed. In any case, I'd be
happy to review and might be completely wrong...


-------------------------

Nick Kew schreef: 
On Mon, 29 Jan 2007 20:31:40 -0600
<devkit1@thevortex.cc> wrote:

  
I have gotten the impression this may be a sore subject for the list
based on searching through the archives, but I do not intend to work
anyone up.  I have been trying to find a solution to the problem of
shared hosting with a dynamic language such as PHP.  I found the old
perchild MPM and it appears it is not being maintained or there was
possibly a design problem.  I would like to know two things.

1. Is there a mechanism (other than suexec) that allows functionality
similar to perchild, that will allow a uid to be assigned on a per
request basis?
    

There are several third-party solutions: google for metux, peruser,
mod_ruid, and fastcgi.

  
2. If there is, do the developers need help with it?  I can write C
and I am willing to help out with this.  If there is not, Would
anyone from the Apache team be interested in working with me so I may
write such functionality, maybe for a future version of Apache?
    

Patches welcome.

Bear in mind that perchild was threaded, and therefore never
likely to be suitable for php.
--------------010308010005080608080203--