4 ms·
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
by post-it 2mo ago
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
- cogman10 2mo agoWell 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 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.
- ddevnyc 2mo agoI 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.
- pixl97 2mo agoThe 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.
- PunchyHamster 2mo agoif 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
- pixl97 2mo agoAnd 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.
- emj 2mo agoYou 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.
- stackghost 2mo ago>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.
- pixl97 2mo agoYep, once you have code execution you find a local privilege escalation and go from there.
- emj 2mo agoThe point is you can not trust that people patch stuff like this in time. So practically you have to make it really hard, in a CTF of course it is easy. Defense is in depth. There are architectural issues, e.g. we only allow one upload per instance., and sanitation is done away from initial upload handling and processing. I would say that even local root is not that bad if you play your cards correctly. (What ever root mean nowdays with CAP dropping etc) Enterprise security can be good if people are paranoid when they build the infra, but as is highlighted in this thread many patch requirements are stupid.