This is what I truly don't like about the CVE system.
One such example is CVE-2023-45853 [1]. Zlib included in it's source an extra set of utilities and add-ons. One such utility, MiniZip, had a buffer overflow vulnerability. BAM, 8.8 CVE (was a 9, looks like they pulled it back a bit). But not one that the 99% of applications using zlib would ever be vulnerable to because almost nobody used the MiniZip utility. It was so unused that the solution for zlib was to simply remove it.
I know about this one particularly because our security policy required us to do a BUNCH of pointless updates for it since zlib is in just about everything.
In the Spack package manager [1] we're trying to work around this with directives:
So, you can define conditional deprecation, and the dependency resolver can still pick up `zlib ~minizip` (i.e. with a variant/component disabled).Deprecation on versions only isn't the right granularity.
[1]: https://github.com/spack/spack/pull/52372
Also a buffer overflow in user space for a tool not serving internet traffic is not a big deal.
I would be careful with this line of thought: opening a malformed archive that gets you into user space is often the first step in a chain-of-attacks that ends up winning Pwn2Own, so I think that a 8-ish score makes sense for it. It won't be enough to do much on its own, but for the past decade or so it's been all about chaining enough small things together to get root, rather than single points of failure.
I keep feeling like the entire CVE system is creaking and about to fail- the signal-to-noise on that has gone so far down, the gate-keeper function that MITRE et al are supposed to be providing clearly has fallen apart, but we do need some way of tracking problems and alerting on bugs in commonly reused libraries. So I can see the problems with the current system, I just can't envision the new, better system to build to replace it.
We should track and fix buffer overflows.
And you’re right, I don’t know all the ways this can be combined with other attacks related to the shell.
But when I design a system the security people at work tell me to assume any bad thing can happen in a user process and design the process isolation and policies to contain it.
Entire categories of attacks (Dos) etc are futile to do anything in user space. Just limit resources and call it a day.
Reminds me of the time our “security” team fought with me for a year to fix an issue in a third-party dependency that was failing their scanners. The issue was only a problem for and intentionally left in to not break support for Internet Explorer 6 on Windows XP, neither of which anyone at the company had used in 10 years, and everyone using this software was on a Mac anyway.
My condolences to anyone who’s got to deal with all these slop-y CVEs on one side and brain dead security teams on the other.
same things happens with npm and CVEs, most of the ones that bubble up aren't even called in my application so are no applicable.
go lang has a scanner [0] which only shows issues when the code actually calls the effected functions.
[0] https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.
Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really.
If you keep driving the "seperate the packages" angle you end up with is-odd, and that not a nice play to be either.
Even more than that, a lot of vulnerabilities require untrusted input to exploit, but the library or executable is usually only used with trusted input. For example, suppose the chacha20 function had a vulnerability that was exploitable with a malicious secret key, but you only call it with your own, definitely not malicious, key. The vulnerability doesn't impact you, but your security policy might still require you to update. And no amount of splitting the package will help with that.
I have concluded that even though I won't use that key, I still want the issue fixed. You never know if the key I randomly choose next year is the vulnerable one. Worse, you never know if someone else won't make a bug that allows outsiders to select a key...
But it doesn't warrant an emergency automatic update.
At least for native binaries it's not too hard to write a scanner that extracts symbols from the binaries and checks them against the symbol names of the vulnerable code. If the code is properly dead and got pruned by the linker, it cannot cause any problems.
Yes it can cause you troubles, even if you don't link to it. Just having a vulnerability scanner (incorrectly) flag it can cause you numerous problems.
Say you distribute your application to a customer and link against libzip, and that customer points to the minizip 8.8 CVE above and says "if you don't fix this vulnerability our scanner is flagging, we are required to stop using your product", that'll cause you plenty of problems even though you don't use nor provide any way to reach the vulnerable code.
That sort of blind CVE adherence is so common in the industry that it's usually easier to do meaningless updates than fight back.
They should be in separate packages so you won't force yourself to patch CVEs in the parts you don't use?
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.
Isn't the real difficulty in how vulnerabilities can be mixed? A given vulnerability might be extremely hard to execute, but very damaging. Another vulnerability might be easier to execute, but it can't do much. But if the second one can be used to trigger the first one, you then have attack surface area of the second vulnerability with the damage of the first one.
Even if some individual case can be shown to be safe from being combined, can we identify such cases with enough confidence to justify using it reduce severity warnings?
Yea, this is where the problems start coming in.
In testing with LLMs with good exploit finding capabilities and a lack of guardrails on writing exploits, quite often LLMs will chain together a surprising stack of exploits to get what they want. They'll get access via a weak, but limited user. They'll search around laterally until they find something else. For example User A (weak exploit) -> User B -> User B bad configuration -> root (or application takeover).
They don't get bored like humans and they can be more robust than a set of scripts by far in catching errors when their scripts don't work or interesting things show up in their findings. The huggingface break down is a good example of just how much lateral movement an LLM can try with enough processing power behind it.
This is where the security onion gets messy. It can be hard to predict when compromising one layer actually bypasses many other layers of your security.
reminds me of the cvss scoring system. that thing is great at telling a story. for better or worse XD.
If the solution was to remove an unused dependency, I think this CVE isn't silly at all.