[peruser] PHP opcode caching and chroot

Hannes Landeholm landeholm at gmail.com
Fri Jan 14 12:23:15 MST 2011


Yes, you could use prefixing to prevent name collision in between
environments but that doesn't address the security issue. As long as
environments share memory with APC there are no way to prevent cache
stealing. The sharing memory part is the root of the problem.

I'm looking at using the mmap
option<http://php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask>now.
Ironically, the same feature which could theoretically allow Fast
CGI processes to share
memory,<http://stackoverflow.com/questions/598444/how-to-share-apc-cache-between-several-php-processes-when-running-under-fastcgi>could
also theoretically be used to prevent processes from sharing memory.
Mmap effectively maps a region memory to a physical file allowing the file
to be used as a handle. This would be perfect for chroot'd environments as
you could then inherit file system permissions to shared memory permissions.
The only problem is that APC is not coded to take advantage of this.
Although it provides an option that uses mmap, it's just another way for it
to share memory the normal way by placing the opened handle in global
memory. It also immediately deletes the file - preventing it from being used
as a memory handle. In addition, APC allocates the shared memory in the
apache module initialization callback before any chrooting has actually
occoured, so to change APC to make use of mmap for real, several changes
would need to be made.

Hannes

On 14 January 2011 19:36, Leen Besselink <leen at consolejunkie.net> wrote:

> On Fri, Jan 14, 2011 at 05:02:52PM +0100, Hannes Landeholm wrote:
> > Hello,
> >
> > FYI, I just tested this on my system and it appears that the shared
> memory
> > can indeed cross the boundary between different environments, so my
> > assumption that this would be blocked somehow was wrong. As Cronfy wrote
> > below, the file caching path collision can be fixed by using a directory
> > structure where the first subfolder in the chroot is unique. This is
> infact
> > the case for our system where we have:
> >
> > ../user1/www.site1.com
> > ../user1/www.example.com
> > ../user2/www.anothersite.com/
> > ....
> >
> > An environment chroot corresponds to a user directory so all paths are
> > unique. Still, this is an unacceptable security issue as the sites now
> share
> > memory with op codes of potentially sensitive information preventing
> threat
> > containment on intrusion. For example, hacking www.site1.com above and
> using
> > apc_bin_dump it would be theoretically possible to get the mysql
> passwords
> > of www.anothersite.com.
> >
> > I'm looking into ways of preventing this...
> >
> > Hannes
> >
>
> I think you would need to set an extra value (like php_admin_value or
> environment
> variable) from Apache with the real path or sitename or similair.
>
> And change the code of the opcode-cache-extension to recognise that extra
> value as a
> key/prefix/whatever to prevent them from having the same path inside the
> opcode
> cache.
>
> A simple change in the path in memory could be enough like:
>
> sitename:/path instead of the current /path
>
> It could be useful if the name of the the variable is configurable like a
> php.ini-setting.
>
> This might be a bit hackish, maybe there is a better way, I guess it also
> depends on the code of the opcode-cache-extension.
>
> >
> > On 11 January 2011 19:55, Cronfy <cronfy at sprinthost.ru> wrote:
> >
> > > Hello,
> > >
> > >
> > >  Also say you have two users who have installed WordPress, you end up
> with:
> > >>
> > >> /home/user1/public_html/wp-config.php
> > >> /home/user2/public_html/wp-config.php
> > >> but Eaccelerator (and xcache, APC) only see this:
> > >> /public_html/wp-config.php
> > >> as the file path. Do we know if it is serving the correct file when a
> > >> request comes in from user1 or user2 or whether it thinks they are the
> same
> > >> file because of the chroot path? I'm just wondering if anyone has come
> > >> across this before with peruser + chroot and knows whether these tools
> are
> > >> working correctly despite the chroot? Or whether there is a way to
> feed the
> > >> full path to these opcode caching tools while using peruser + chroot.
> > >>
> > >
> > > Not sure if it will help, but you may try to add site name to the path
> to
> > > make it different:
> > >
> > > /home/user1/wordpress-me.com/public_html/wp-config.php
> > > /home/user2/wordpress-yourself.com/public_html/wp-config.php
> > >
> > > Anyway, I agree with Hannes:
> > >
> > >
> > >  In fact, it would be a security risk of one environment could access
> > >>
> > > the cached PHP files of another environment
> > >
> > > And access to shared memory between different users should be
> thoroughly
> > > tested.
> > >
> > >
> > > --
> > > // cronfy
> > >
> > > _______________________________________________
> > > Peruser mailing list
> > > Peruser at telana.com
> > > http://www.telana.com/mailman/listinfo/peruser
> > >
>
> > _______________________________________________
> > Peruser mailing list
> > Peruser at telana.com
> > http://www.telana.com/mailman/listinfo/peruser
>
> _______________________________________________
> Peruser mailing list
> Peruser at telana.com
> http://www.telana.com/mailman/listinfo/peruser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.telana.com/pipermail/peruser/attachments/20110114/44a8ea57/attachment.htm>


More information about the Peruser mailing list