Comment by post-it
11 hours ago
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
11 hours ago
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
Well that's the thing, to build the utilities required extra flags which were pretty rarely enabled. You can, in most distros, ultimately install minizip as a separate package but few do. It's not that useful of a utility. Most people will likely just grab the full blown "zip" application https://infozip.sourceforge.net/Zip.html . Though on linux, even more people are simply using tar with a zlib extension. That's the `tar.gz` files.
I think this presents a highly fascinating scenario:
1. A vulnerability that presents itself very rarely
2. If it presents itself, it is fatal to the organization
So, few targets are affected, but the outsized effect means that the overall economic impact is not insignificant. How does one keep track of that?
One method is to use a sort of "kirchhoff's law" approach, similar to google page rank. The electrical analogy would be:
- the attacker has a high potential, let's say 1000V. that attacker is the root of a rose tree, going from top to bottom, branching out towards the bottom.
- nodes impossible to exploit present edges with infinite resistance
- nodes that can be exploited present finite resistance (perhaps very low)
- once a node is exploited, its node branches out to other things that now become accessible and may or may not be exploited
- real economic impact presents a connection to ground, measured as 1/($economic impact) ohms resistance
Once you have a structure like that, you can measure the hypothetical current that would be flowing, and measure the severity of such exploits.
Sometimes a single path through a complex system can blow up vital, important parts, and this could be one way to measure it in some sort of objective manner.
The hard part is accurately making that flow chart. You have your software composition you have to keep accurate. Your software configuration and it's changes. Environmental systems and its changes like VM hosts and network hardware. And network pathing and firewalling.
When does something become a ground can be very difficult to figure out with the above complexity.
if the tool isn't ran it can't be exploited
CVE should just be far more granular instead of flagging alert for anything using zlib
And when you chain another weak CVE to run the tool in a method that would have previously been a noop?
Security can be a major pain in the ass, and it's pretty often we see CVEs that were low valued suddenly become more urgent when someone finds a better way to use them as an exploit.
You do not run it as root, all you get is the possibility to crash or execute code. Nodes that handle such things are all heavily locked down.
>all you get is the possibility to [...] execute code
Anyone who's ever done even a beginner CTF knows that achieving code execution is a big deal.
Yep, once you have code execution you find a local privilege escalation and go from there.