httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <devk...@thevortex.cc>
Subject Re: State of perchild MPM
Date Tue, 06 Feb 2007 00:28:48 GMT



On Wed, 31 Jan 2007 11:15:23 +0100, Arnold Daniels <info@adaniels.nl> wrote:
> 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.
>>
>>
> 
> 


Mime
View raw message