PHP exploit leaks before fix, emergency updates out

[Ranulfo]

Is one of your favorite websites or forums offline today or since yesterday? New php exploit is likely the cause:

https://arstechnica.com/security/20...are-themselves-for-critical-security-patches/

"Unconfirmed report claims PHP2Shell exploit remotely executes code on PHP sites."

Website admins, brace yourselves. Fixes for what are believed to be uncommonly severe vulnerabilities are scheduled to drop in a little more than 12 hours for PHP, a programming language that powers websites and Web applications everywhere.


PHP maintainers said Monday that they planned to release patches for two vulnerabilities, both with severity ratings of 9.2 out of a possible 10.

From GoG this morning, website, forums and even galaxy launcher is offline:

 

[FrgMstr]

Handled here already, just FYI.

 

[Nobu]

Yeah, got an email from the openwrt forum, said site was down pending a patch.

 

[Aurelius]

I don't think I've ever seen website hosts race to install security updates so quickly. Then again, there were some researchers who said attacks could start almost immediately. Better to take your site down mid-day than to risk someone hijacking it, mind you...

 

[Ranulfo]

I don't think I've ever seen website hosts race to install security updates so quickly. Then again, there were some researchers who said attacks could start almost immediately. Better to take your site down mid-day than to risk someone hijacking it, mind you...

Kiwifarms shut down last night 12+ hours ahead of time to wait until the updates were out officially.

 

[uOpt]

What's the bug(s), exactly?

 

[Lakados]

What's the bug(s), exactly?

The exploit targets a core memory flaw in the PHP interpreter during standard HTTP POST request processing. When a user uploads a form, PHP automatically updates an internal element counter before allocating memory for the data. By submitting an excessively large form field, an attacker intentionally triggers a fatal memory exhaustion error, abruptly killing the request. Because the process is killed mid-way, PHP is left in an incomplete state: the element counter is incremented, but the actual memory slot is left uninitialized, filled instead with attacker-controlled bytes left over from previous server requests.
During the subsequent automatic cleanup routine, PHP trusts its internal counter and visits this uninitialized memory slot. It misinterprets the attacker's leftover bytes as valid memory pointers and is tricked into following them. This triggers a low-level callback that executes arbitrary system commands with the privileges of the web server worker, resulting in unauthenticated Remote Code Execution (RCE).

 

[auntjemima]

Handled here already, just FYI.

Let's hope so... I don't need people finding all of my gay posts..

 

[uOpt]

The exploit targets a core memory flaw in the PHP interpreter during standard HTTP POST request processing. When a user uploads a form, PHP automatically updates an internal element counter before allocating memory for the data. By submitting an excessively large form field, an attacker intentionally triggers a fatal memory exhaustion error, abruptly killing the request. Because the process is killed mid-way, PHP is left in an incomplete state: the element counter is incremented, but the actual memory slot is left uninitialized, filled instead with attacker-controlled bytes left over from previous server requests.
During the subsequent automatic cleanup routine, PHP trusts its internal counter and visits this uninitialized memory slot. It misinterprets the attacker's leftover bytes as valid memory pointers and is tricked into following them. This triggers a low-level callback that executes arbitrary system commands with the privileges of the web server worker, resulting in unauthenticated Remote Code Execution (RCE).

Thanks so much.

And the bad thing is that php applications can usually overwrite their own code on disk, because that is how updates work from within that php app. Great.

 

[erek]

 

[toast0]

Thanks so much.

And the bad thing is that php applications can usually overwrite their own code on disk, because that is how updates work from within that php app. Great.

That's a messy practice... Better if the user php runs as can't touch the document root, but then wordpress won't auto update because they don't want you to habe to setup a cron job. *sigh*

Anyway, even without that, php can usually writr *somewhere* and then you can run a ddos bot or a cryptominer or something.