Working with PaloAlto to identify CVE-2024-2550
1–10 of 21 posts
Re: Working with PaloAlto to identify CVE-2024-2550
#2Interesting that they use Go. I'd have thought most products in this space would be using C or C++.
Re: Working with PaloAlto to identify CVE-2024-2550
#3I 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”?
Re: Working with PaloAlto to identify CVE-2024-2550
#4I 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”?
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
Re: Working with PaloAlto to identify CVE-2024-2550
#5Interesting that they use Go. I'd have thought most products in this space would be using C or C++.
Caught me by surprise as well
Re: Working with PaloAlto to identify CVE-2024-2550
#6Interesting 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.
Re: Working with PaloAlto to identify CVE-2024-2550
#7Interesting that they use Go. I'd have thought most products in this space would be using C or C++.
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.
Re: Working with PaloAlto to identify CVE-2024-2550
#8I 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.
Re: Working with PaloAlto to identify CVE-2024-2550
#9Out of curiosity, is this article partially ai-generated?
Re: Working with PaloAlto to identify CVE-2024-2550
#10Interesting that they use Go. I'd have thought most products in this space would be using C or C++.
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.