Prevent changing PHP parameters via .htaccess (php-fpm by pass)

E

erick85

Verified User
Joined
Oct 20, 2020
Messages
65
Do you have any way to prevent PHP running in FPM from changing parameters via .htaccess? I'm testing this kind of scripting and I'm worried that through SetEnv PHP_VALUE (eg. SetEnv PHP_VALUE "open_basedir = /" ) I can change absolutely every parameter including open_basedir and memory_limit. Of course, I know that php.ini can't be the only security on the server (folder/file permissions etc), but that's not the point. Limits and parameters in php.ini must be controlled regardless. From what I can see, someone reported this bypass as a bug in PHP (https://bugs.php.net/bug.php?id=79417&edit=1) but I don't think anyone is going to do anything about it.
 
Last edited:
just disable "htscanner", Normally php-fpm will unable support directive value, it always done via ".user.ini" file
 
jamgames2 said:
just disable "htscanner", Normally php-fpm will unable support directive value, it always done via ".user.ini" file
Click to expand...
It's disabled:
# ./build set_php htscanner no
htscanner is already set to no
Click to expand...
and even deprecated like said @smtalk

Also note that I am not writing about the option:
php_value open_basedir /
(this actually causes error 500)

but:
SetEnv PHP_VALUE "open_basedir = /"
 
Last edited:
erick85 said:
It's disabled:

and even deprecated like said @smtalk

Also note that I am not writing about the option:
php_value open_basedir /
(this actually causes error 500)

but:
SetEnv PHP_VALUE "open_basedir = /"
Click to expand...

Probably the best way to restrict this is to patch Apache. Something like:

Code: 
--- modules/metadata/mod_env.c.orig     2018-07-02 07:49:16.000000000 -0500
+++ modules/metadata/mod_env.c  2023-02-22 11:14:12.047824592 -0600
@@ -151,7 +151,7 @@
 AP_INIT_ITERATE("PassEnv", add_env_module_vars_passed, NULL,
      OR_FILEINFO, "a list of environment variables to pass to CGI."),
 AP_INIT_TAKE12("SetEnv", add_env_module_vars_set, NULL,
-     OR_FILEINFO, "an environment variable name and optional value to pass to CGI."),
+     RSRC_CONF|ACCESS_CONF, "an environment variable name and optional value to pass to CGI."),
 AP_INIT_ITERATE("UnsetEnv", add_env_module_vars_unset, NULL,
      OR_FILEINFO, "a list of variables to remove from the CGI environment."),
     {NULL},

This would prevent SetEnv from being an allowed directive in the .htaccess file, but would allow it within server config files (i.e. httpd.conf or Include files).

If someone happens to have a legitimate use for using SetEnv then it would have to be included via the main Apache configuration file by someone with root access - who presumably knows what they're doing.
 
sparek said:
Probably the best way to restrict this is to patch Apache. Something like:
Click to expand...
Hmm, just one more question where/how to implement it so that it doesn't break with DA? :D
P.S. SetEnvIf and SetEnvIfNoCase commands cannot set PHP_VALUE?
 
Well, DirectAdmin could add that patch to their Apache building script. Or I think you can add your own patches through CustomBuild, but I'm not sure what other patches have been applied before the custom patches get applied, so the above verbatim might not be exactly correct.

But upon looking at this, it appears that there are at least a handful of cases where SetEnv is used in .htaccess. It looks like Owncloud and Magento may make use of this. Does it also control mod_gzip (mod_deflate?) controls as well?

Disabling SetEnv in .htaccess file using the above patch as a guide would seem to be the easiest solution... but I'm not exactly clear on what ramifications this may have and that would need to be investigated first.
 
It's a pity that there is no module or simply Apache configuration that allows you to scan .htaccess before loading it. In the case of a found phrase, Internal Server Error should appear and that's it.

@smtalk maybe this is a challenge for you (I saw that you were the author of the htscanner module)? :> Now that you have disabled secure suPHP, it would be a good idea to secure the remaining option now :)
 
I suppose you could remove the ability for php-fpm to read PHP_VALUE and PHP_ADMIN_VALUE environment variables.

Something like:

Code: 
--- sapi/fpm/fpm/fpm_main.c.orig        2023-02-22 12:37:30.721629835 -0700
+++ sapi/fpm/fpm/fpm_main.c     2023-02-22 12:37:47.833164172 -0700
@@ -1319,7 +1319,7 @@
        }
 
        /* INI stuff */
-       ini = FCGI_GETENV(request, "PHP_VALUE");
+/*     ini = FCGI_GETENV(request, "PHP_VALUE");
        if (ini) {
                int mode = ZEND_INI_USER;
                char *tmp;
@@ -1335,7 +1335,7 @@
                spprintf(&tmp, 0, "%s\n", ini);
                zend_parse_ini_string(tmp, 1, ZEND_INI_SCANNER_NORMAL, (zend_ini_parser_cb_t)fastcgi_ini_parser, &mode);
                efree(tmp);
-       }
+       } */
 }
 /* }}} */

Although... it's worth noting that even from the bug report you listed - https://bugs.php.net/bug.php?id=79417&edit=1

I guess the reason why you can overwrite it is just that SetEnv in Apache adds FCGI env. The PHP_ADMIN_VALUE and PHP_VALUE is something that allows overwriting PHP ini on the server and it's been always there. It's on purpose and we can't change it as it would likely break some applications.

That's going to suck if I have to go back to compiling PHP - because it's an every month thing... multiple versions. Even just testing this was a 10 minute compile.
 
erick85 said:
But you need to keep PHP_ADMIN_VALUE for user php-fpmXX.conf :(
Click to expand...
This should still work. At least it does for me when I do a simple test in a not-so-DirectAdmin hosting environment.

Commenting out the lines in fpm_main.c according to that patch (which was for vanilla PHP 8.2.3 by the way... I would assume it's similar for all PHP versions, but didn't go that far) just removes the ability for PHP_VALUE and PHP_ADMIN_VALUE Environment values to be applied, i.e. the SetEnv PHP_VALUE "open_basedir = /" you can include in your .htaccess file. You can keep it in your .htaccess file, but it won't have any bearing on the PHP running on the website.

I'm not trying to claim that this is THE answer. I'm just reporting what I'm finding. Other people need to review this and try it out and see if it fixes the issue and what problems might be faced. The concern I always have is that the person suggesting the patch (i.e. me in this case) tends have tunnel vision as to how this applies to the problem. Other people that try and implement the solution may find issues the original patcher couldn't foresee.
 
You must log in or register to reply here.
Back
Top