You know, when Linux admins say "don't run as root!" we don't only mean that users should not run as root. Nothing that doesn't absolutely have to should run as root.<p>And before someone says "but only root can read those files!", please take this opportunity to learn about filesystem ACLs. <a href="https://linux.die.net/man/1/setfacl" rel="nofollow">https://linux.die.net/man/1/setfacl</a><p>edit: Also, yes, this would not have fully solved the problem, but it is very likely that the amount of potential harm that could have been caused would have been significantly reduced.
I just wrote this up elsewhere, but wow, is that Python code awful. It uses string interpolation to build a curl command line. Then it passes that string to a subprocess.Popen(cmd,shell=True). For those who don’t speak Python, that’s saying “run the string passed in here as a shell command exactly as if someone typed it into a bash prompt”. The right thing to to there would have been to create a list of arguments and pass that list in instead of a string, and set shell=False so that the list gets sent straight to the underlying syscall without being parsed and interpreted as a command line, with all the edge cases that brings.<p>As worryingly, the free, open source Bandit Python static analyzer immediately flagged this code when I tested it locally. If Palo Alto had any kind of static analysis in their build pipeline, this would have failed. If they’re not doing that, what else are they not doing?
The combination of multiple bad behavior strung together is really interesting. I imagined the author of each bad behavior was unaware of the other bad behaviors and was basically like "what's the worst they can do?"<p>I feel a lot of good exploits work this way where each small bad behavior can be leverages to magnify another.
The arb file write with uncontrolled (empty) content being turned into exec due to another process is certainly an interesting find.<p>Usually arb file create bugs with no control of content are at best a DoS unless there’s another issue at play :)
like most products connected to the internet, VPNs and firewalls can have vulnerabilities too. As long as its not super low hanging fruit that should have been caught or is a bad default configuration, its the response that matters the most to me.
A few days ago, a colleague saw a port/service scan:<p>> <i>User-Agent: Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo@paloaltonetworks.com</i><p>I could maybe see that for license enforcement, or for aggressively alerting users to the vulnerability even in absence of active service contracts.<p>Could also be someone <i>other than</i> PAN, looking for vulnerable PAN boxes.