Hi, We have a server hosting PHP websites of several distinct organizations (users). Each organization should run its php scripts under its own Unix user. It should not be possible for user Bob to cause Apache to execute stuff as user Alice by manipulating the .htaccess of his own site. In the old days, we used to use Suexec plus a binfmt for PHP to achieve this. However, a while ago, for performance reasons, we switched to php-fpm over Unix Domain Sockets. By default the php-fpm backend does not enforce any default directory nor ownership before executing a PHP script as a user. I.e. if Bob connects to Alice's FPM pool (or somehow causes Apache to do so on his behalf), it will happily execute /home/bob/public_html/hack.php with the rights of user alice. Bob (or an intruder having compromised his CMS) could do this by (temporarily) including the following into his own site's .htaccess: Sethandler "proxy:unix:/run/php/php-fpm-alice.sock|fcgi://localhost" It seems to be rather difficult for the server administrator to adequately prevent this. 1. Simply removing AllowOverride FileInfo is not doable, as many CMSes depend on having other FileInfo directives present in their .htaccess file. 2. There seems to be no other way, such as a <Proxy ...> section, to restrict which origin server SetHandler may connect to. Indeed SetHandle ignores any <Proxy ...> section, or at least any Require all granted / denied included therein. Interestingly, other directives that allow to connect to FPM, such as ProxyPass and RewriteRule do honor <Proxy...> sections (in a way, see below...), but for those the point is moot, as ProxyPass is never allowed in .htaccess, and using RewriteRule to connect to an UDS is broken when called from .htaccess (misparses proxy url, and tries to find a module mod_proxy_unix.so instead of mod_proxy_fcgi.so) 3. Enforcing security on the FPM side (by setting php_value[open_basedir] in the pool definition) may not be sufficient as: - there could be directories that PHP needs be able read, but which it should not execute programs from - it would still allow to bypass any Apache-based password authentications or other filters that the rightful webmaster (Alice) has set up Eventually, we resorted to remove FileInfo from AllowOverride, and to instead add all other needed FileInfo directives one-by-one using AllowOverrideList. However, this seems needlessly cumbersome, especially since example files supplied by some distributions do include AllowOverride FileInfo into their default config files (such as /etc/apache2/mods-available/userdir.conf in Debian) Any comments about the future plans for security of SetHandler? Also, <Proxy> enforcement for ProxyPass is weird: it only matches against the fcgi://localhost/localpath part, and completely ignores the UDS part unix:/run/php/php-fpm-alice.sock , making it impossible to give Bob access to only his own FPM pool definition but not to Alice's. For RewriteRule, it works correctly (matches against full string), but I'm concerned this could change in a later fix for the issue about it looking for the wrong module when called from .htaccess. Moreover, I'm concerned that there could be other directives than SetHandler, AddHandler, ProxyPass and RewriteRule that could be abused to redirect Apache to a wrong origin server. Thanks, Alain --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|