Working with PaloAlto to identify CVE-2024-2550
ac3.com.auInteresting that they use Go. I'd have thought most products in this space would be using C or C++.
Given their major competitor Fortigate had multiple exploitable buffer overflow vulnerabilities this year that's probably a good thing.
I wonder if it's a recent rewrite. My GlobalProtect on PAN-OS 11.0 is unusable after 11.0.2 with the entire company unable to connect. The latest release presumably fixed it, but Linux clients still unable to get a stable connection.
i share your pain. in my 20+ yrs working on enterprise infrastructure, i have never come across a more garbage product on so many levels on so many platforms at the same time as GlobalProtect.
How does it compare to Microsoft Teams?
Nice thing about Cisco AnyConnect and ASA firewalls is that they are rock solid.
It's still mostly C, with bits of Python, Go, and other common languages sprinkled around, plus more esoteric things for the platforms with ASICs or other specialized hardware.
And that in turn is all running on a nice layer of CentOS 6
I would see the use of a garbage collected C as an improvement, even if the language's design could be so much better.
Remember the evolution of UNIX at AT&T ended up on Inferno, not Plan 9.
Was your supposition because security appliance vendor track record in using generally insecure tech foundations, or that Go is too new?
It's just that I work in an adjacent area. It's not so much a question of security but of legacy, history, and performance. When Palo Alto was founded, 2005, I think C/C++ would basically be the only choice for these sorts of quasi-embedded/realtime high performance security applications. Then once you've built some sort of ecosystem around a certain technology introducing new technologies becomes harder.
Yes, I was imagining something like this for the "too new" alternative.
In 2005 you did already have safer, capable, mature systems programming languages available, eg Ocaml, but for cultural reasons they were not often used in SV. And people were less educated about building secure software (goes double for enterprise security products).
Caught me by surprise as well
I feel like I’m missing something.
Isn’t this blog post effectively “we patched our firewall, things broke, we made a support case, and the vendor investigated and filed a CVE”?
It seems like they provided a decent bug report.
Lots of vendors dismiss support issues without strong data. But if you go to the length of decoding the request, outlining the steps to reproduce etc you can have a much faster experience. Especially with network vendors where 99%+ of their support workload is dealing with client or reseller misconfiguration.
Its maybe a bit trumped up, it smells a bit like MSP marketing but its also at least a little bit warranted?
Actually I was in a similar place with Palo 24 months or so ago, and despite handing them everything they could possibly expect they handed us a workaround (Just bounce your vpn sessions manually when they fail) instead of issuing a patch. However there was a strong argument there that our customer was a bit too dedicated to their wacky vpn architecture and should be doing things differently. Really the kudos here is getting the vendor to perform which I feel is a huge skill these days.
felt the same tbh.. - u won't believe how many trouble previously was needed to go through to get this vendor to acknowledge a CVE >.> - hard to believe this is the whole story.. maybe they learnt finally not to try and shove shit under the carpet. who knows. I doubt it.
Op here. It was but a very muddy timeline... there was also a wildfire cve which I didn't detail due to how it was discovered (long story) but playing responsible is good!
Long story short. We patched the firewall things broke... we spoke to TAC they had no idea kept just saying it was client so we went log digging realised it was a DoS and sent it over to PSIRT and they confirmed it and raised the CVE
Out of curiosity, is this article partially ai-generated?