Hacker News new | past | comments | ask | show | jobs | submit
cogman10 | on: SQLite Critical CVEs or LLM Slop?
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.

[1] https://app.opencve.io/cve/CVE-2023-45853

stabbles | parent | next
In the Spack package manager [1] we're trying to work around this with directives:

    deprecated("@:1.3 +minizip", reason="cve", severity="high")
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

groundzeros2015 | parent | next
Also a buffer overflow in user space for a tool not serving internet traffic is not a big deal.
loading story #49157552
vorticalbox | parent | next
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

pico303 | parent | next
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.

realityking | parent | next
IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.
loading story #49156142
loading story #49156100
post-it | parent | next
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
loading story #49155353
loading story #49155631
loading story #49155929
SkyBelow | parent | next
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?

loading story #49157659
unknown_user_84 | parent | next
reminds me of the cvss scoring system. that thing is great at telling a story. for better or worse XD.
dncornholio | parent
If the solution was to remove an unused dependency, I think this CVE isn't silly at all.