I'm actually somewhat surprised at the clumsiness here.
I'm a complete amateur that had DeepSeek build a PHP2Shell exploit, and once the stealmybitcoin site went up and set an upload limit, i had DeepSeek try to shrink/amplify it.
DeepSeek couldn't find anything but a 2x reduction, but reading the report of how it was done - https://github.com/KillaBoi/StealMyBitcoin-PoC - I was somewhat surprised it didn't find it, and equally horrified at PHP allowing such a memory bomb of creating nested objects by parsing `f[0][x][x]...` from random requests.
Point being; these aren't amateurs but i kind of expect most well funded pros to have found this method to avoid sending massive filenames and session progress data.
no I was doing a back and forth council with chatgpt and it was fun chatgpt wouldn't do it but deepseek did and it pushed each other further it was really cool
cost me $10 in the end to run it fo about 10 hours straight, since I hit it in daytime hours
Years ago I talked to an ex-msft guy whose comment on Samba was "they're repeating all of the same mistakes we made". It was a tongue-in-cheek comment about how compatible Samba was with Microsoft's SMB implementation.
On Android many things available on Desktop Linux are disabled by selinux. For example, af_alg algorithm (encryption kernel module writes out of bounds) is not accessible by user using ADB.
> Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
IIRC it was CVE-2026-31431 earlier this year that made me go audit what modules were loaded and go on a whole hardening kick. As far as I understood, the vulnerable module (algif_aead) wasn't even commonly used by anything.
So why is it loaded by default? It's just an extra code path to potentially exploit my system with. It's even marked deprecated (and insecure!), yet a fresh NixOS (and Arch, I believe) install has it loaded out of the box.
I mean, I get it, broad compatibility and all that jazz... but still.
Everything is enabled by default in Linux, it's just their way. Privilege escalation exploits for Linux are found every year. If you can RCE a Linux box, assume you can also get root.
Reading this I'm almost certain the firewall vendor is Palo Alto Networks. They included a PAN-OS setting verbatim and the SELinux config matches my experience.
Why does a world-class firewall stack need PHP? I'm sure PAN-OS has some neat DPI features, but I would love to see firewalls that are implemented in FPGA, where the tasking was compiled down to gates to be performed deterministically, much like the low port count network switches we have today.
> Irrational hatred aside, that's literally what PHP was designed for.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
This is great to say with the benefit of hindsight but nobody is changing the underlying language of their well established product for literally no reason.
And that is even with the assumption that other languages don't have issues - they do.
I’ve never worked anywhere that would have done that. If you have a Sec analysis and it says you have vulnerabilities you harden and fix those vulns. You don’t just say “ok full rewrite in $HOT_LANGUAGE!” For one thing, you’ll have to retrain or replace your entire team, who may mostly be $OLD_LANGUAGE specialists. And either feature freeze, or carry on feature development thus needing a larger team, and making the spec a moving target for the porting team.
Now, do I think that it may be more likely in 2027 than it was in 2007 or 2017? Absolutely. Depends on how well-documented and specified your existing system is. A rust rewrite or whatever is highly possible now for many codebases, probably.
I get that logically you would think that a very wealthy company would improve their technology once they had the resources to do that. But companies do not run by logic. They run by humans, making human decisions, motivated by almost every conceivable thing except logic.
> When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you
.... are still run by the same startup people who think "working like a startup" was a good idea in the first place.
Right now I work with a bunch of people who came up working for startups. They are responsible for the products that make the company the most money. They are still on PHP 7.4.
For some reason I’m not allowed to respond to the child comment so I’m putting this here:
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.
My last comment on this: it is not "one URL" or "just configuration pages", it is an entire application, it does not have distinct "pages" that can be replaced with something written in a different programming language.
You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.
> You can always take a look at the UI of a PAN device
I do not have a PAN device.
> it is not "one URL"
I never implied it was.
> it is an entire application, it does not have distinct "pages"
> the concept of a web application
Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.
If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.
> Since this discovery, the Dream research team has been sharing updates and collaborating on an investigation with Palo Alto Networks, the vendor of the firewall in question. More information is available on the Palo Alto Networks website. Additional details are now included in the post itself.
This makes me kinda furious. The us government makes me do so much goddamned work to comply with their cyber security regulations (only about half of which actually contribute to my security posture), and here they are running their fucking firewall management page publicly exposed (the globalprotect portal was not vulnerable, only the _actual_ management page).
Remember that the non-defense sector of the government has been having cuts for decades and lots of important work is outsourced to rotating contract teams. This is definitely unacceptable but I'd bet there were more than a few people there who were profoundly unsurprised that the backlog caught up with them.
The title is misleading as the article says "including systems in a US government-affiliated environment" which reads more like a 3rd party the government is contracted with versus actual government systems.
Is there an important difference there? If it’s a contractor doing official government business, the fact it’s a contractor, and not running software written by public servants on metal that sits on US government property… is more of an implementation detail, isn’t it? The system would have the same importance and function, and contain the same data, whether or not this particular function had been outsourced.
For our US friends, as context, this is akin to Rudy Giuliani being a cybersecurity expert. Partly, because it simply never was Sebastian Kurzs area of expertise, mainly because the referenced corruption scandal centered around the use of Whatsapp to facilitate said corruption, so, you know...
I sometimes wonder if this is the true function of leaders in a democracy. To serve as a scapegoat so that the electorate has somebody to blame for all the unsolved problems in their life. It's psychologically much easier to believe that you're held down by the government and discharge responsibility for fixing your life to your government leaders than it is to take the long, challenging and often risky steps toward improving your actual life. Also, people who do take the latter path often end up with noticeably better lives over the years, and yet few people take that path.
Note that electing clowns to public office is not unique to NYC - we've had a reality TV star and an actor as POTUS (the latter also serving as governor of California), Toronto has elected a criminal as mayor, Minnesota got a pro-wrestler as governor, South Korea had multiple presidents resign in disgrace, and South America seems to have politicians ping-pong between prison and presidency.
He has already IT experience then. Surely he learned something out of it. Securely using apps. Discretely handling deals, etc.
Anyway from their webpage:
> We work directly with heads of state, ministries, national cyber authorities, and the senior officials responsible for executing national strategy.
So I presume he has and provides contacts. Just the usual one hand washes the other. Nothing nefarious I'm sure.
LMAO, you mean he learned to install Signal and turn on disappearing messages after all of his chat messages, obviously implying corrupt political practices, were read in a special government committee?
The guy doesn't even know what DHCP is, "I'm sure".
I almost feel bad that company is getting traffic from HN. Kurz is such a disgusting little worm.
Extremely wrong. I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone. Exploiting the PHP request parser bypasses basically all security checks and it doesn't matter how secure your code is because the exploitable component runs before your code and can't be disabled.
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
"There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day."
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
This exploit depends on the deployment. With PHP-FPM, an OOM during request startup terminates the child, so the corrupted state wouldn’t survive for subsequent requests to exploit. The challenge used PHP’s built-in server, where the worker was reused.
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
In online communities right now there’s a lot of demand for evidence of LLM capabilities being overblown. It’s unfortunate that even if the steal my bitcoin creator apologizes for spreading misinformation due to incompetence, the truth won’t be spread as widely.
Shutting down half the internet was the right move. If it took someone 19 hours to exploit a site, you'd better have shut it down before 19 hours and not after.
I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.
Also, unless I am reading this wrong, it does not seem like what actually got the bitcoin was a 2shell-like exploit? Seems like memory corruption leading to printing out the flag through just http requests? How would you use this outside of a CTF context?
2shell is catchy shorthand for "do anything". log4shell (originator of the name?) didn't directly give you a shell either, it ran some Java code. You could have a shell if you wanted to.
I think it goes back to the huge amount of anti-AI sentiment that's out there today. Any AI accomplishment gets undersold by haters, i.e. people maintaining that the Navier-Stokes solution was stolen, people saying that Lean proofs can't be relied on, exploits like PHP2Shell are esoteric and not usable in the real-world, etc. Those are just comments I recall reading off the top of my head but I could find sources if anyone wants. I think it's just a way for people to cope and fool themselves into thinking that this whole AI thing isn't a big deal and will just blow over.
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
There were prominent people saying stuff like "this bug is so bad, every PHP server is vulnerable to any script kiddie with an LLM; simultaneously, my exploit is so valuable and secret that I don't want to tell you what it is; also although I could totally steal this bitcoin, I choose not to, but I totally could if I wanted to".
Which is pretty indistinguishable from people just lying about how bad it is? How are you meant to tell the difference? How can it both be true that the server is vulnerable to any script kiddie with an LLM but your exploit is too valuable to share?
And the fact that the server turned out to be not exploitable just proves that the people claiming to be able to exploit it in fact were lying.
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
Under normal configurations the server is highly exploitable.
It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.
The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )
>I don't understand what's with all the flat infosec society coming out of the woodwork.
Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?
Where is all the evidence of exploits if most of the webs PHP servers were vulnerable?
This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.
You only care about this because it falls into a weird viral narrative about "AI saftey".
> I am very curious to hear why you thought it was overblown.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
You could configure your web server to only allow one request per worker, which means the corrupted memory can not get used by the attacker. Not great for performance, obviously.
You can do this. I don't know how, and I don't think it's a feasible use of my time, to find out how. It's obviously computable on a Turing machine, because they were able to patch PHP.
So it was useless advice? You presented it as if anyone not following the advice is incompetent, now you suggest nobody knows how to do it. Is everyone incompetent?
What? I never claimed it was "advice"? I explained how other people could have arrived at the conclusion that there can be worse things than a single language interpreter being vulnerable to a unconditional RCE. Were you answering to the wrong comment?
The configuration change was never a full protection from this vulnerability because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
> because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
That's what I wrote? You can't do anything once PHP executed. It could still be worse, because you can still prevent PHP from running, because there is still the webserver before. If it were in the webserver itself, you couldn't do anything, short of stopping the server from running.
> The configuration change was never a full protection from this vulnerability
It is, if the configuration change prevents PHP from running. That's how you could say it is overblown. You are not vulnerable if you don't run PHP.
You kept talking about some configuration change that makes things "overblown", without making it clear you meant "turn off PHP". So yes that's misinformation.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix
The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
> And that's assuming you actually meant "turn off PHP" the entire time?
I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
> The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.
Its overblown in the sense that 70% of the internet was not in fact vulnerable, as widely reported. And not everyone is a hackor because they have access to llms. Go look at normie coverage from people like Linus tech tips and you'll see them saying how millions of servers were under attack by script kiddies with llms, amd how llms are so dangerous.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
I agree. There's nuance to it. I believe the CVE was overblown, and I also believe that it is a severe vulnerability that should be addressed ASAP. 2 things can be true at once.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
The CVE was not overblown. It's correctly marked as a 9.2.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
Respect, hats off to reevaluate when presented with the info. Will fully admit, I myself lacked the ability to assess the true severity, mainly cause I try to stay away from PHP since my first encounter in sixth grade, so was going a bit back-and-forth due to what I was reading.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
Yes, you were. These exploits are happening in processes like php-fpm before it actually executes any code for the web application, so its not like you need to find endpoint where a specific class is being invoked or anything like that.
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I find statements like yours to not be about objective truth, but rather a narcissistic view of world where if it was hard for you, it must not be possible. It is more of a comparison of yourself vs the world.
Hi all. Reading these every day now. Is public cloud safe anymore or the internet in general? Or are we just choosing to live in a reality where their mondo security budgets head off these exploits - and yeah, naw - coming clean is still more expensive than burying incidents?
Edit: “Or the internet in general” - and yes internet was never safe but this is just next level. You seem to do everything right and it doesn’t matter. Is o365 really safe for example? I’m rapidly seeing my faith in SaaS platforms degrade - they can’t be immune to all
Of this
That's wild, I remember in early 2000s it was super easy to upload a PHP file with a shell. Back when hostings were shared, one shell could get you access to the whole host.
So logical flaws can't be patched without hardware replacement? Software isn't fundamentally unsafe. We're in a gap era where the capability to discover bugs is greater than the response time and pre-emptive hardening of software written without AI assistance. This gap will eventually get smaller.
I don't know, strange things happen. The other day I had to rotate a bunch of credentials because a coop cloned a private repo, made it public, and checked in a .env file with production database credentials... 5 years ago. And they still worked. No idea how that wasn't exploited, honestly.
Nah, I guess it is Palo Alto. PHP and Appweb is their stack AFAIK. Forti does not use PHP, Juniper uses Appweb with PHP but on FreeBSD - but the article mentions SELinux.
I'd be happy to answer that question if you posed it straight, rather than as a an attempted dunk. Of course, the search bar on this thread will lead you to plenty of additional conversation about the vulnerability and the attempts to downplay it.
You seem to be reading too hard into what I said. I wasn't giving you an exhaustive list of where the snark lies. I was saying where it started.
Edit: From your reply of "Great work? Do you want a cert to prove how well you perform the function of forum peanut gallery?" it looks like you have abandoned the claim I was being suspiciously selective. Good! We're settled then. I'm going to ignore your weird new goalpost where you get annoyed that someone clarified themselves.
it probably starts with a correct and safe authorization check, but this vulnerability happens before any user code runs, so every PHP page is vulnerable.
True-ish? If your firewall's admin page is internet-accessible, you have no excuse for not doing "bolted to bedrock" lockdowns of your web server config and your PHP config. Either of which could have blocked exploitation of the PHP vuln.
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.
> A1 — Memory Exhaustion (~383MB):
I'm actually somewhat surprised at the clumsiness here.
I'm a complete amateur that had DeepSeek build a PHP2Shell exploit, and once the stealmybitcoin site went up and set an upload limit, i had DeepSeek try to shrink/amplify it.
DeepSeek couldn't find anything but a 2x reduction, but reading the report of how it was done - https://github.com/KillaBoi/StealMyBitcoin-PoC - I was somewhat surprised it didn't find it, and equally horrified at PHP allowing such a memory bomb of creating nested objects by parsing `f[0][x][x]...` from random requests.
Point being; these aren't amateurs but i kind of expect most well funded pros to have found this method to avoid sending massive filenames and session progress data.
Interesting, my deepseek session did find it.
You probably just have added “find all exploits” and “breathe slowly, relax, and focus”…
Sorry, I still resent the moronic 2024 “Prompt Engineering” guides that were obviously bullshit and non-falsifiable random claims.
Some of it did have merit. The "think step-by-step" trick is nowadays formalised in chain-of-thought reasoning.
no I was doing a back and forth council with chatgpt and it was fun chatgpt wouldn't do it but deepseek did and it pushed each other further it was really cool
cost me $10 in the end to run it fo about 10 hours straight, since I hit it in daytime hours
this featured is disabled in any security conscious deployed (which doesn't seem to be the case for some large firewall vendor)
My Qwen3.8-27B was able to do it.
> the attacker chained in a second exploit: a Linux kernel vulnerability in the XFRM ESP-in-TCP subsystem
Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
E.g. this came out today: CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation [1].
I just disabled mptcp on my systems since I don't use it. Why was it enabled by default?
Can I disable this XFRM thing too?
[1] https://www.penligent.ai/hackinglabs/cve-2026-98432/
The bug doesn't mention MPTCP, is MPTCP required for the bug to be exploitable?
No, but MPTCP makes it more likely to be exploited, supposedly.
SMB in the kernel and binding io_uring to DMABUF doesn't look pretty safe either.
Torvalds needs to borrow Rust code from Asterinas (and maybe Redox) ASAP.
Years ago I talked to an ex-msft guy whose comment on Samba was "they're repeating all of the same mistakes we made". It was a tongue-in-cheek comment about how compatible Samba was with Microsoft's SMB implementation.
I'm on Gentoo and when I compile my kernel, by default, almost nothing is enabled.
On other distros they throw in the kitchen sink because it is easier than making an endless amount of them customized to every system.
Gentoo seems like a nice in between to standard distros and unikernels.
You can build your own kernel on any distribution fwiw
On Android many things available on Desktop Linux are disabled by selinux. For example, af_alg algorithm (encryption kernel module writes out of bounds) is not accessible by user using ADB.
> Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
IIRC it was CVE-2026-31431 earlier this year that made me go audit what modules were loaded and go on a whole hardening kick. As far as I understood, the vulnerable module (algif_aead) wasn't even commonly used by anything.
So why is it loaded by default? It's just an extra code path to potentially exploit my system with. It's even marked deprecated (and insecure!), yet a fresh NixOS (and Arch, I believe) install has it loaded out of the box.
I mean, I get it, broad compatibility and all that jazz... but still.
Everything is enabled by default in Linux, it's just their way. Privilege escalation exploits for Linux are found every year. If you can RCE a Linux box, assume you can also get root.
The XFRM thing is probably Dirty Frag, patched several months ago.
Reading this I'm almost certain the firewall vendor is Palo Alto Networks. They included a PAN-OS setting verbatim and the SELinux config matches my experience.
Further indication is that PHP 7.4.33 and PHP 8.30.0 are mentioned which are an exact match for PAN-OS 11.1/11.2 and 12.1/12.2 respectively
Why does a world-class firewall stack need PHP? I'm sure PAN-OS has some neat DPI features, but I would love to see firewalls that are implemented in FPGA, where the tasking was compiled down to gates to be performed deterministically, much like the low port count network switches we have today.
What else would you use to power the configuration gui frontend? Allow me to eliminate some of the obvious and inevitable answers:
- Rust didn't exist at the time
- Go didn't exist at the time
- nodejs didn't exist at the time
- Java and Python likely used too much resources for a once-in-a-while used GUI
Irrational hatred aside, that's literally what PHP was designed for.
> Irrational hatred aside, that's literally what PHP was designed for.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
This is great to say with the benefit of hindsight but nobody is changing the underlying language of their well established product for literally no reason.
And that is even with the assumption that other languages don't have issues - they do.
> literally no reason
PHP being big and creaky was very well known. This has nothing to do with hindsight.
And it still is big and creaky. You can cite this comment the next time something like this happens to prove it's not hindsight bias.
> And that is even with the assumption that other languages don't have issues
Incorrect. Please do not strawman.
At which point during that 20 years do you decide to rewrite a ton of your production code just to change languages?
When you are making a lot of money and have a security analysis of your stack.
I’ve never worked anywhere that would have done that. If you have a Sec analysis and it says you have vulnerabilities you harden and fix those vulns. You don’t just say “ok full rewrite in $HOT_LANGUAGE!” For one thing, you’ll have to retrain or replace your entire team, who may mostly be $OLD_LANGUAGE specialists. And either feature freeze, or carry on feature development thus needing a larger team, and making the spec a moving target for the porting team.
Now, do I think that it may be more likely in 2027 than it was in 2007 or 2017? Absolutely. Depends on how well-documented and specified your existing system is. A rust rewrite or whatever is highly possible now for many codebases, probably.
I get that logically you would think that a very wealthy company would improve their technology once they had the resources to do that. But companies do not run by logic. They run by humans, making human decisions, motivated by almost every conceivable thing except logic.
> When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you
.... are still run by the same startup people who think "working like a startup" was a good idea in the first place.
Right now I work with a bunch of people who came up working for startups. They are responsible for the products that make the company the most money. They are still on PHP 7.4.
I wonder if that's why Palo and PanOS have had so many vulnerabilities this year and last
Lua? Tcl? both AFAIK have less vulnerabilities than PHP likely thanks to smaller code size.
> What else would you use to power the configuration gui frontend?
Perl?
For some reason I’m not allowed to respond to the child comment so I’m putting this here:
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
When discussing programming languages, you need to take into consideration how easy it is to find developers with experience on a certain language.
Sure, you can do web apps in Perl with Catalyst or other frameworks, but the PHP developers are easier to find.
And then, after you develop entire GUIs in a language, it is a herculean effort to port that to another.
And lastly, JavaScript has its own issues too.
We're talking about an html GUI right? That's not herculean to port between languages.
The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.
But that glue is pretty straightforward and you only have to convert one page at a time.
I don’t think you ever went through something like this ever.
It is a huge effort even migrating from one PHP framework to another.
Coming back to your point, there is no single “page” to be migrated one at a time.
It's just the configuration pages. It's not the core of the product and doesn't need to be a perfect clone.
Is there a reason one URL at a time wouldn't work?
My last comment on this: it is not "one URL" or "just configuration pages", it is an entire application, it does not have distinct "pages" that can be replaced with something written in a different programming language.
You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.
> You can always take a look at the UI of a PAN device
I do not have a PAN device.
> it is not "one URL"
I never implied it was.
> it is an entire application, it does not have distinct "pages"
> the concept of a web application
Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.
If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.
We were talking about early 2000s.
Perl 5 was the language of choice for CGI in that era, but PHP borrowed some of perl syntax and quickly displaced Perl in web usage.
Some perl programmers migrated to Embperl, but it didn't gain much momentum.
You win.
Perl 4 specifically of course though.
> Perl 4 specifically of course though.
Not in 2005. Perl 5 all the way, baby!
That's for mission-critical load-bearing infrastructure hidden behind modernized interfaces. Nobody has touched that script in 33 years.
> Since this discovery, the Dream research team has been sharing updates and collaborating on an investigation with Palo Alto Networks, the vendor of the firewall in question. More information is available on the Palo Alto Networks website. Additional details are now included in the post itself.
This makes me kinda furious. The us government makes me do so much goddamned work to comply with their cyber security regulations (only about half of which actually contribute to my security posture), and here they are running their fucking firewall management page publicly exposed (the globalprotect portal was not vulnerable, only the _actual_ management page).
Remember that the non-defense sector of the government has been having cuts for decades and lots of important work is outsourced to rotating contract teams. This is definitely unacceptable but I'd bet there were more than a few people there who were profoundly unsurprised that the backlog caught up with them.
The government tends to have the magical combination of total power combined with low to moderate skill.
The title is misleading as the article says "including systems in a US government-affiliated environment" which reads more like a 3rd party the government is contracted with versus actual government systems.
Is there an important difference there? If it’s a contractor doing official government business, the fact it’s a contractor, and not running software written by public servants on metal that sits on US government property… is more of an implementation detail, isn’t it? The system would have the same importance and function, and contain the same data, whether or not this particular function had been outsourced.
public markets point to FORTINET
Dream is btw founded and led by Sebastian Kurz, who was head of the Austrian government. He had to step down because of a corruption scandal.
For our US friends, as context, this is akin to Rudy Giuliani being a cybersecurity expert. Partly, because it simply never was Sebastian Kurzs area of expertise, mainly because the referenced corruption scandal centered around the use of Whatsapp to facilitate said corruption, so, you know...
Well it's more like Rudy Giuliani starting a bitcoin company regardless of his expertise in any one particular area right, which basically has happened a couple times now: https://www.ai-cio.com/news/former-associates-rudy-giuliani-...
The NY politician to grifter pipeline is interesting (Giuliani, Adams, Cuomo).
You sure it's not a grifter to NY politician pipeline?
All my NYC relatives seem to have choice (unfavorable) words to say about every single one of their politicians, and have ever since Koch's 3rd term.
It's hard to serve 11M people, so most people who get into that position do so by promising to serve 11M people and then serving themselves.
New York's favorite thing to do is vote in the worst people and then complain nonstop.
I sometimes wonder if this is the true function of leaders in a democracy. To serve as a scapegoat so that the electorate has somebody to blame for all the unsolved problems in their life. It's psychologically much easier to believe that you're held down by the government and discharge responsibility for fixing your life to your government leaders than it is to take the long, challenging and often risky steps toward improving your actual life. Also, people who do take the latter path often end up with noticeably better lives over the years, and yet few people take that path.
Note that electing clowns to public office is not unique to NYC - we've had a reality TV star and an actor as POTUS (the latter also serving as governor of California), Toronto has elected a criminal as mayor, Minnesota got a pro-wrestler as governor, South Korea had multiple presidents resign in disgrace, and South America seems to have politicians ping-pong between prison and presidency.
I think you're maybe kind of right. We convince ourselves that politicians are idiots so we elect idiots.
I think the biggest change is we don't really hold them accountable anymore, at least in western democracies. Maybe we never really did.
And non-partisan!
He has already IT experience then. Surely he learned something out of it. Securely using apps. Discretely handling deals, etc.
Anyway from their webpage: > We work directly with heads of state, ministries, national cyber authorities, and the senior officials responsible for executing national strategy.
So I presume he has and provides contacts. Just the usual one hand washes the other. Nothing nefarious I'm sure.
LMAO, you mean he learned to install Signal and turn on disappearing messages after all of his chat messages, obviously implying corrupt political practices, were read in a special government committee? The guy doesn't even know what DHCP is, "I'm sure". I almost feel bad that company is getting traffic from HN. Kurz is such a disgusting little worm.
Dream has Kurz only as sales guy. The two Israeli/ex-mossad guys are running the ship.
One of the three co-founders also founded NSO Group, and was developing the Pegasus malware.
Just for context, that is the type of evil we're talking about here.
A German comedian made an episode about it [1]
[1] https://youtube.com/watch?v=_PF23EdGNcE
[flagged]
I thought we were smug about how hard it was to make a working exploit for this?
Smugness an excellent way to accelerate the timeline
The most likely outcome is the most entertaining one
Sometimes I think cybersecurity should practice similar superstitions of the maritime industry
The initial claims being put out was everything will be getting hacked 15 minutes after the patch drops. Turns out it took a lot longer than that.
If you are still running an old PHP version you are grossly incompetent and should take your server offline.
Did it? The article says they discovered the compromise on October 25th.
You had me at PHP
perhaps i was wrong
https://news.ycombinator.com/item?id=50272530
Extremely wrong. I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone. Exploiting the PHP request parser bypasses basically all security checks and it doesn't matter how secure your code is because the exploitable component runs before your code and can't be disabled.
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
"There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day."
19 hours: https://stealmybitcoin.com/
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
It's not 19hours. The server was originally configured with no running php. Once they added a php file, the server got pwned in 2 hours.
Interesting. I did not know that. (Obviously.)
This exploit depends on the deployment. With PHP-FPM, an OOM during request startup terminates the child, so the corrupted state wouldn’t survive for subsequent requests to exploit. The challenge used PHP’s built-in server, where the worker was reused.
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
In online communities right now there’s a lot of demand for evidence of LLM capabilities being overblown. It’s unfortunate that even if the steal my bitcoin creator apologizes for spreading misinformation due to incompetence, the truth won’t be spread as widely.
Shutting down half the internet was the right move. If it took someone 19 hours to exploit a site, you'd better have shut it down before 19 hours and not after.
I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.
Also, unless I am reading this wrong, it does not seem like what actually got the bitcoin was a 2shell-like exploit? Seems like memory corruption leading to printing out the flag through just http requests? How would you use this outside of a CTF context?
https://github.com/KillaBoi/StealMyBitcoin-PoC
2shell is catchy shorthand for "do anything". log4shell (originator of the name?) didn't directly give you a shell either, it ran some Java code. You could have a shell if you wanted to.
I think it goes back to the huge amount of anti-AI sentiment that's out there today. Any AI accomplishment gets undersold by haters, i.e. people maintaining that the Navier-Stokes solution was stolen, people saying that Lean proofs can't be relied on, exploits like PHP2Shell are esoteric and not usable in the real-world, etc. Those are just comments I recall reading off the top of my head but I could find sources if anyone wants. I think it's just a way for people to cope and fool themselves into thinking that this whole AI thing isn't a big deal and will just blow over.
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
There were prominent people saying stuff like "this bug is so bad, every PHP server is vulnerable to any script kiddie with an LLM; simultaneously, my exploit is so valuable and secret that I don't want to tell you what it is; also although I could totally steal this bitcoin, I choose not to, but I totally could if I wanted to".
Which is pretty indistinguishable from people just lying about how bad it is? How are you meant to tell the difference? How can it both be true that the server is vulnerable to any script kiddie with an LLM but your exploit is too valuable to share?
And the fact that the server turned out to be not exploitable just proves that the people claiming to be able to exploit it in fact were lying.
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
The point is, under normal configurations when you're serving the PHP server correctly with table-stakes best practices the server is not exploitable
This was not a scary vuln at all.
Under normal configurations the server is highly exploitable.
It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.
The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )
>I don't understand what's with all the flat infosec society coming out of the woodwork.
Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?
Are you sure this isn’t already happening?
Normal configuration of a PHP server is to not run any PHP code and serve a static html file?
Where is all the evidence of exploits if most of the webs PHP servers were vulnerable?
This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.
You only care about this because it falls into a weird viral narrative about "AI saftey".
There's nothing separate about this.
Chained just means they used php2shell to run a local privilege escalation.
Was the exploit not dependent on a kernel exploit that was disclosed and patched in may, or am I just hallucinating?
Depends which part: php2shell does what it says on the tin: lets you run arbitrary commands as www-data.
If you want more than that you need to chain an LPE. Which are plenty these days sadly.
Which best practices did you use to prevent exploitability?
And would you stake your bitcoin on it?
I had a similar take, but I was wrong.
How were you wrong? Out of 15k targets scanned they arrived at 25 servers total.
> I am very curious to hear why you thought it was overblown.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
Can you? Initial suggestions to block multipart content-types were a red herring.
In theory yes. In practice, I don't know, I hope my provider patched it properly.
What specific configuration would you recommend to block the vulnerability without actually patching it?
You could configure your web server to only allow one request per worker, which means the corrupted memory can not get used by the attacker. Not great for performance, obviously.
None. Like I wrote "I don't know, I hope my provider patched it properly."
Then why did you say
> you can prevent PHP being executed on malicious data by configuring the webserver.
Configure your webserver to not execute PHP code.
You can do this. I don't know how, and I don't think it's a feasible use of my time, to find out how. It's obviously computable on a Turing machine, because they were able to patch PHP.
So it was useless advice? You presented it as if anyone not following the advice is incompetent, now you suggest nobody knows how to do it. Is everyone incompetent?
What? I never claimed it was "advice"? I explained how other people could have arrived at the conclusion that there can be worse things than a single language interpreter being vulnerable to a unconditional RCE. Were you answering to the wrong comment?
> I don't know how
You are spreading misinformation then.
The configuration change was never a full protection from this vulnerability because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
> You are spreading misinformation then.
?
> because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
That's what I wrote? You can't do anything once PHP executed. It could still be worse, because you can still prevent PHP from running, because there is still the webserver before. If it were in the webserver itself, you couldn't do anything, short of stopping the server from running.
> The configuration change was never a full protection from this vulnerability
It is, if the configuration change prevents PHP from running. That's how you could say it is overblown. You are not vulnerable if you don't run PHP.
So basically what you're saying is you aren't vulnerable if you turn off your website.
The server configuration to mitigate this is to comment out the whole configuration so there's no server.
You kept talking about some configuration change that makes things "overblown", without making it clear you meant "turn off PHP". So yes that's misinformation.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
Edit: stray "not"
My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix
The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
> And that's assuming you actually meant "turn off PHP" the entire time?
I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
> The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
> And that conclusion is basically meaningless.
That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.
Reminds me a recent article that went viral on HN, claiming: "There isn't an easy exploit for this PHP vulnerability"..
https://news.ycombinator.com/item?id=50188948
Its overblown in the sense that 70% of the internet was not in fact vulnerable, as widely reported. And not everyone is a hackor because they have access to llms. Go look at normie coverage from people like Linus tech tips and you'll see them saying how millions of servers were under attack by script kiddies with llms, amd how llms are so dangerous.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
I agree. There's nuance to it. I believe the CVE was overblown, and I also believe that it is a severe vulnerability that should be addressed ASAP. 2 things can be true at once.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
The CVE was not overblown. It's correctly marked as a 9.2.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
This was a vulnerability worse than Heartbleed. Did they hear about Heartbleed?
Respect, hats off to reevaluate when presented with the info. Will fully admit, I myself lacked the ability to assess the true severity, mainly cause I try to stay away from PHP since my first encounter in sixth grade, so was going a bit back-and-forth due to what I was reading.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
Yes, you were. These exploits are happening in processes like php-fpm before it actually executes any code for the web application, so its not like you need to find endpoint where a specific class is being invoked or anything like that.
I commend you to having corrected your thoughts this publicly fwiw.
We need more of this.
Perhaps you violated Clarke's First Law
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I find statements like yours to not be about objective truth, but rather a narcissistic view of world where if it was hard for you, it must not be possible. It is more of a comparison of yourself vs the world.
See also https://news.ycombinator.com/item?id=50224916 https://news.ycombinator.com/item?id=50225703
I am confused. Is this attack possible even after the PHP patches OR these servers just didn't patch ?
> The affected devices run specific versions of a large vendor’s firewall software.
And the vendor's firewall software runs an unpatched version.
I bet it's fortinet.
Or Palo Alto networks
This is 100% PAN-OS
Hi all. Reading these every day now. Is public cloud safe anymore or the internet in general? Or are we just choosing to live in a reality where their mondo security budgets head off these exploits - and yeah, naw - coming clean is still more expensive than burying incidents?
Edit: “Or the internet in general” - and yes internet was never safe but this is just next level. You seem to do everything right and it doesn’t matter. Is o365 really safe for example? I’m rapidly seeing my faith in SaaS platforms degrade - they can’t be immune to all Of this
Maybe we going to have to shut down the Internet soon. Maybe it won’t be such a bad thing to become more local and decentralized again.
> For security purposes, we are not disclosing the vendor or the affected versions
Wat
That's wild, I remember in early 2000s it was super easy to upload a PHP file with a shell. Back when hostings were shared, one shell could get you access to the whole host.
[flagged]
With software being fundamentally unsafe I see everything hardwired in chips.
FPGA stocks? DV is about to become hot again..
So logical flaws can't be patched without hardware replacement? Software isn't fundamentally unsafe. We're in a gap era where the capability to discover bugs is greater than the response time and pre-emptive hardening of software written without AI assistance. This gap will eventually get smaller.
It sounds like multiple things were misconfigured on these servers and they still have access?!?
Why are there any management interfaces exposed to the Internet at all?
I don't know, strange things happen. The other day I had to rotate a bunch of credentials because a coop cloned a private repo, made it public, and checked in a .env file with production database credentials... 5 years ago. And they still worked. No idea how that wasn't exploited, honestly.
(I wasn't around for this, I just found it)
Wild, I hope the challenge on HN didn't contribute to this.
> Claude Code had been installed
I just do not understand. CC is not the sole harness in the world, why the attackers insist to use it.
Firewalls are likely fortinet
Nah, I guess it is Palo Alto. PHP and Appweb is their stack AFAIK. Forti does not use PHP, Juniper uses Appweb with PHP but on FreeBSD - but the article mentions SELinux.
Haha woopsie
Now let’s watch the goalposts shift in real time about how severe this vulnerability is.
Most goalposts I’ve seen say “bad but clumsy”.
Believe it or not in cybersecurity there are many considerations in how “bad” a vulnerability is.
Practioners are pretty well settled on how big a deal platform-wide RCE is.
They are, and again, believe it or not, more goes into it than “RCE bad”.
Ease of exploitation, feasibility do play a part which I’m sure surprises you.
Not in the sense that people downplaying this vulnerability meant.
What does that even mean?
I'd be happy to answer that question if you posed it straight, rather than as a an attempted dunk. Of course, the search bar on this thread will lead you to plenty of additional conversation about the vulnerability and the attempts to downplay it.
[flagged]
> Believe it or not
> which I’m sure surprises you
You caused the problem here. You started off being hazy and rude.
"Say that again without trying to dunk on anyone if you want me to put effort into responding." seems like a pretty reasonable trade.
[flagged]
My ability to recognize snark is not carrying water for anyone. It started with your very first comment.
Your ability to recognize snark is suspiciously selective too.
Weird.
You seem to be reading too hard into what I said. I wasn't giving you an exhaustive list of where the snark lies. I was saying where it started.
Edit: From your reply of "Great work? Do you want a cert to prove how well you perform the function of forum peanut gallery?" it looks like you have abandoned the claim I was being suspiciously selective. Good! We're settled then. I'm going to ignore your weird new goalpost where you get annoyed that someone clarified themselves.
[flagged]
Since you're intent on being obtuse, here's an example of a thread of HN downplaying the severity of this last week.
https://news.ycombinator.com/item?id=50189820
You actually participated in it and called cyber security researchers addicted to likes. Ironic.
how does this have anything to do with the original post?
also, psuedo cybersecurity researchers are definitely addicted to likes.
edited: looks like half of that post even agrees with them so i mean...?
With all that said, how exploit chaining is working these days I think most peoples considerations are not weighted toward bad enough.
Same here, though what stuck with me is that a firewall's admin PHP page was reachable from the internet at all, keep that on a mgmt VLAN.
it probably starts with a correct and safe authorization check, but this vulnerability happens before any user code runs, so every PHP page is vulnerable.
True-ish? If your firewall's admin page is internet-accessible, you have no excuse for not doing "bolted to bedrock" lockdowns of your web server config and your PHP config. Either of which could have blocked exploitation of the PHP vuln.
What's the right level of lockdown? Starting a page with "if not authorized, return 403" would've seemed adequate before this.
I'd suggest reading https://github.com/php/php-src/blob/master/php.ini-productio..., then doing a web search for "editing php.ini for maximum security".
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:
Zero of these recommendations have anything to do with the present vulnerability.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]