On Wed, 31 Jan 2007 11:15:23 +0100, Arnold Daniels <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>> Aan: 'Arnold Daniels' <[EMAIL PROTECTED]>, <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 >> <[EMAIL PROTECTED]> 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. >> >> > >
