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 .

 

[Ohm J]

hope PHP docker container update soon too, I have some application move to docker

 

[Freddy]

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 .

I ran the test with all the checkboxes on and it failed on a PHP 8.4 website. The technical details say it got a 403 header but my modSecurity log doesn't show anything. So is the test really working?

 

[Clunk]

Had some fun, together with Gemini, forcefully migrating old joomla and wordpress sites which where not governed by installatron on da.
It scared me a bit trusting an AI but I have to say it came through with a big W Now all is 8.3 and the wait starts...

 

[zEitEr]

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 .

Tested some sites after applied both fixes in PHP and Nginx and some without fixes in Nginx here:

- https://php2shell.aikido.io/

and it reports:

So can not confirm anything either.

 

[mcormick]

I ran the test with all the checkboxes on and it failed on a PHP 8.4 website. The technical details say it got a 403 header but my modSecurity log doesn't show anything. So is the test really working?

I've seen the requests come in, one of them being a really long array in the query string. In my case ModSec blocked the requests.
If you have Cloudflare on your domain, I read they updated their WAF rules. In that case requests might not reach your server.