Critical PHP updates

[zEitEr]

There're suggestions to use the following settings in php.ini for a temporary mitigation. But there're no evidences it helps:

- PHP:

session.upload_progress.enabled = Off
session.use_strict_mode = 1

Other sources suggest blocking multipart requests:

- Apache with a help of mod_rewrite:

RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]

- Nginx:

if ($http_content_type ~* "multipart") {return 403;}

An HTTP multipart request is an HTTP request that HTTP clients construct to send files and data over to an HTTP Server. It is commonly used by browsers and HTTP clients to upload files to the server.

All POST requests and file-uploads might stop working after applying the patch to NGINX/Apache.

 

[Freddy]

Cloudflare has rules in place to mitigate known attacks. Does modSecurity with owasp or comodo rules do anything good on DirectAdmin?

 

[Hosted Power]

Jo from Hosted Power here (we run a fair number of DirectAdmin servers).

@brinkie @adam12: for the 7.x boxes that won't get an upstream fix, we wrote a small PHP extension this morning and open-sourced it, in case it helps anyone here.

It switches off the session upload-progress handler (where the researchers who reproduced the bugs placed them) at PHP startup. So it targets the same thing as session.upload_progress.enabled = Off, with two differences: a user's .user.ini or .htaccess can't turn it back on, and it covers every PHP version on the box (5.6 to 8.5). Uploads keep working. The repo has the DirectAdmin steps, including a CustomBuild post-hook so a PHP rebuild doesn't drop it. You can check it per version, e.g.: /usr/local/php74/bin/php --ri hp_uploadprogress_guard

GitHub - HOSTED-POWER/php_uploadprogress_guard

Contribute to HOSTED-POWER/php_uploadprogress_guard development by creating an account on GitHub.

github.com

To be honest about its limits, in line with what @zEitEr and @Freddy said: there's no evidence yet that upload-progress mitigations are enough, and if the bug turns out to be reachable outside that handler, ours won't cover that part either. It's a few hours old, and it doesn't replace the new PHP builds @fln mentioned; install those as soon as they're out. We'll check it against the official advisory at 16:00 CEST and report back here either way.

 

[altayevrim]

I assume that PHP7.x will stay still vulnerable even after the official patch arrives?

 

[zEitEr]

I assume that PHP7.x will stay still vulnerable even after the official patch arrives?

as soon as PHP patches are available, DA team might apply them to PHP 5.x and 7.x whenever it is possible

 

[mcormick]

https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell : Exploitation has been reported in the wild, and the previously suggested configuration mitigations do not protect against these vulnerabilities.
You can check whether your website is affected via aikido.io .