Working with PaloAlto to identify CVE-2024-2550 • Hacker News Board

Re: Working with PaloAlto to identify CVE-2024-2550

#11

Post by ricktdotorg » Mon, Dec 02, 2024, 4:06 AM UTC

whs wrote: post #7

YZF wrote: post #2

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

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.

Re: Working with PaloAlto to identify CVE-2024-2550

#12

Post by fulafel » Mon, Dec 02, 2024, 6:17 AM UTC

YZF wrote: post #2

Interesting that they use Go. I'd have thought most products in this space would be using C or C++.

Was your supposition because security appliance vendor track record in using generally insecure tech foundations, or that Go is too new?

Re: Working with PaloAlto to identify CVE-2024-2550

#13

Post by sim7c00 » Mon, Dec 02, 2024, 8:14 AM UTC

jwcrux wrote: post #3

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”?

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.

Re: Working with PaloAlto to identify CVE-2024-2550

#14

Post by pjmlp » Mon, Dec 02, 2024, 8:28 AM UTC

YZF wrote: post #2

Interesting that they use Go. I'd have thought most products in this space would be using C or C++.

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.

Re: Working with PaloAlto to identify CVE-2024-2550

#15

Post by lidder86 » Mon, Dec 02, 2024, 10:50 AM UTC

sim7c00 wrote: post #13

jwcrux wrote: post #3

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”?

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!

Re: Working with PaloAlto to identify CVE-2024-2550

#16

Post by [deleted] » Mon, Dec 02, 2024, 1:11 PM UTC

[deleted]

Re: Working with PaloAlto to identify CVE-2024-2550

#17

Post by Shadowmist » Mon, Dec 02, 2024, 3:09 PM UTC

ricktdotorg wrote: post #11

whs wrote: post #7

Earlier quoted context omitted.

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?

Re: Working with PaloAlto to identify CVE-2024-2550

#18

Post by UltraSane » Mon, Dec 02, 2024, 7:52 PM UTC

whs wrote: post #7

YZF wrote: post #2

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

Nice thing about Cisco AnyConnect and ASA firewalls is that they are rock solid.

Re: Working with PaloAlto to identify CVE-2024-2550

#19

Post by YZF » Tue, Dec 03, 2024, 3:38 AM UTC

fulafel wrote: post #12

YZF wrote: post #2

Interesting that they use Go. I'd have thought most products in this space would be using C or C++.

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.

Re: Working with PaloAlto to identify CVE-2024-2550

#20

Post by fulafel » Tue, Dec 03, 2024, 5:56 AM UTC

YZF wrote: post #19

fulafel wrote: post #12

Earlier quoted context omitted.

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