Then similar for your web server (Apache, nginx, whatever).
EDIT: About your "would've seemed adequate before this" - I dug up a copy of a PHP v5.2 php.ini file (2-ish decades ago). That file begins thus:
;;;;;;;;;;;
; WARNING ;
;;;;;;;;;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult php.ini-recommended
; and http://php.net/manual/en/security.php.
As far as I know, there has been no proven vulnerability on a modern PHP (production) stack. The "Steal my Bitcoin" challenge was a toy project. The "lab" target used the embedded PHP server (`php -S`) which is for development only.
1. mod_php which is obsolete and requires Apache prefork (which should also be avoided)
2. php-fpm (FastCGI) which has been the default for more than a decade.
3. FrankenPHP is a new official interface much more suitable for containers.
There were 2 vulnerabilities.:
1. "OOM corruption".
The advisory says there was a proven exploit with mod_php, but only for that obsolete SAPI. "Source analysis therefore supports FPM as a susceptible, though *no complete FPM exploit* has been demonstrated for this SAPI."
2. "stale global state".
The advisory is
The last PHP release (8.5) was vulnerable when the debug parameter fatal_error_backtraces was on. There was a suspicion that an exploit could exist in the session code for php-fpm, but it was unproven and probably unrealistic.
The "evidence" given at the end of the article seems old news to me. The honeypot was based on Apache-prefork + mod_php. As stated in the CVE, there is a proven exploit for that (obsolete) stack.
So why did the original warning put out by the PHP team say that the exploit didn't rely on the application code and simply having software like Apache mod_php running would be enough?
Who remembers how careless, reckless, and blithe Rasmus Lerdorf was with the PHP 5.3.7 release he didn't bother to test, because running tests was too much of a hassle, because there were already so many test failures that wading through them all to see if there were any new ones was just too much to ask of him, the leader of the widely used project, in charge of cutting releases?
>5.3.7 upgrade warning: [22-Aug-2011] Due to unfortunate issues with 5.3.7 (see bug#55439) users should postpone upgrading until 5.3.8 is released (expected in a few days).
No seriously, he's literally as careless as he claims to be (when he says that repeatedly, you should believe him!), and his lack of giving a shit about things like tests and encryption and security that are extremely important has caused actual serious security problems, like breaking crypt() by checking in sloppy buggy code that would have caused a unit test to fail, but without bothering to run the unit tests (because so many of them failed anyway, so who cares??), and then MAKING A RELEASE of PHP 5.3.7 with, OF ALL THINGS, a broken untested crypt()!
Does anyone think that's just his sense of humor, a self deprecating joke, breaking then releasing crypt() without testing, that's funny in some context? What context would that be? Do they just laugh and shrug it off with "lol let Rasmus be Rasmus! ¯\_(ツ)_/¯ "?
>You can see the code coverage, test case failures, Valgrind reports and more for each branch.
>The crypt change did trigger a test to fail, we just went a bit too fast with the release and didn't notice the failure. This is mostly because we have too many test failures which is primarily caused by us adding tests for bug reports before actually fixing the bug. I still like the practice of adding test cases for bugs and then working towards making the tests pass, however for some of these non-critical bugs that are taking a while to change we should probably switch them to XFAIL (expected fail) so they don't clutter up the test failure output and thus making it harder to spot new failures like this crypt one.
Great that its out but if you depend on pecl for additional extensions and need to rebuild docker container it will probably fail because pecl is having issues for last few hours[1].
As I mention elsewhere (https://bugs.php.net/bug.php?id=78876) I'm very confused. Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked? But then the report makes less sense.
> PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Earlier versions are not fixed by PHP official and need vendor patching where available
> We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
I'm not seeing any discussion here about woeful web application architectures from the 1990s still in use?
The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.
The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.
Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.
Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?
edit: also nominating the shared $_SESSION state of PHP that was typical a decade ago to just be left to default (e.g. all PHP processes just read/write session files to a common /tmp directory). https://www.php.net/manual/en/function.session-set-save-hand... should probably instead be used by web application developers to somehow better isolate session state between users.
Due to an upcoming significant vulnerability disclosure with no official mitigation, services are currently offline as a precaution. Services will not be restored until at least later in the day on October 21. This time may also be spent on additional maintenance, so this message may be periodically unavailable.
>Where immediate patching is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is available.
It seems serious. Well, good luck isolating all PHP applications from the public internet...
> Do not use extract() on untrusted data, like user input (e.g. $_GET, $_FILES). If you do, make sure you use one of the non-overwriting flags values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.
Looks like calling it can shadow previously defined, unrelated variables?
Edit: On re-reading your comment, yes, if $requiredHeaders is previously sanitized then the code is technically safe. But it still presents as an insecure coding practice.
Maybe compare with https://github.com/php/php-src/blob/master/php.ini-developme..., too.
Then similar for your web server (Apache, nginx, whatever).
EDIT: About your "would've seemed adequate before this" - I dug up a copy of a PHP v5.2 php.ini file (2-ish decades ago). That file begins thus: