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.
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