[peruser] PHP opcode caching and chroot

Leen Besselink leen at consolejunkie.net
Fri Jan 14 13:23:05 MST 2011


On 01/14/2011 08:23 PM, Hannes Landeholm wrote:
> 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.
>

Oops, forgot about that part. :-)

> 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.
>

Not sure if you prefer APC over xcache, but I think xcache has mmap
support too. Maybe it does it differently ?

> Hannes
>
> On 14 January 2011 19:36, Leen Besselink <leen at consolejunkie.net
> <mailto: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 <http://www.site1.com>
>     > ../user1/www.example.com <http://www.example.com>
>     > ../user2/www.anothersite.com/ <http://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
>     <http://www.site1.com> above and using
>     > apc_bin_dump it would be theoretically possible to get the mysql
>     passwords
>     > of www.anothersite.com <http://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
>     <mailto: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
>     <http://wordpress-me.com/public_html/wp-config.php>
>     > > /home/user2/wordpress-yourself.com/public_html/wp-config.php
>     <http://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 <mailto:Peruser at telana.com>
>     > > http://www.telana.com/mailman/listinfo/peruser
>     > >
>
>     > _______________________________________________
>     > Peruser mailing list
>     > Peruser at telana.com <mailto:Peruser at telana.com>
>     > http://www.telana.com/mailman/listinfo/peruser
>
>     _______________________________________________
>     Peruser mailing list
>     Peruser at telana.com <mailto:Peruser at telana.com>
>     http://www.telana.com/mailman/listinfo/peruser
>
>



More information about the Peruser mailing list