6 ms·

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-o

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 https://app.opencve.io/cve/CVE-2023-45853

unknown_user_84 3mo ago
reminds me of the cvss scoring system. that thing is great at telling a story. for better or worse XD.
post-it 3mo ago
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
- cogman10 3mo ago
  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 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 3mo ago
    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.
    - pixl97 3mo ago
      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.
- PunchyHamster 3mo ago
  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
  - pixl97 3mo ago
    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.
- emj 3mo ago
  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.
  - stackghost 3mo 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 3mo ago
      Yep, once you have code execution you find a local privilege escalation and go from there.
      - emj 2mo ago
        The 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.
stabbles 3mo ago
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 https://github.com/spack/spack/pull/52372
dncornholio 3mo ago
If the solution was to remove an unused dependency, I think this CVE isn't silly at all.
realityking 3mo ago
IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.
- inigyou 3mo ago
  They should be in separate packages so you won't force yourself to patch CVEs in the parts you don't use?
- delusional 3mo ago
  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.
  - gmueckl 3mo ago
    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.
    - TheDong 3mo ago
      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.
  - 3mo ago
pico303 3mo ago
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.
SkyBelow 3mo ago
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?
- pixl97 3mo ago
  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.
vorticalbox 3mo ago
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 https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
groundzeros2015 3mo ago
Also a buffer overflow in user space for a tool not serving internet traffic is not a big deal.
- mandevil 3mo ago
  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.
  - groundzeros2015 3mo ago
    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.
sam_lowry_ 3mo ago
> our security policy required us Nope, someone should have requested that from you directly or indirectly, but you should not have done the pointless job if you have a pointy one usually. If you obey, it degrades you and the society at large.

unknown_user_84 3mo ago

reminds me of the cvss scoring system. that thing is great at telling a story. for better or worse XD.

post-it 3mo ago

But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.

cogman10 3mo ago
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 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 3mo ago
  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.
  - pixl97 3mo ago
    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.
PunchyHamster 3mo ago
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
- pixl97 3mo ago
  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.
emj 3mo ago
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.
- stackghost 3mo 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 3mo ago
    Yep, once you have code execution you find a local privilege escalation and go from there.
    - emj 2mo ago
      The 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.

stabbles 3mo ago

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 https://github.com/spack/spack/pull/52372

dncornholio 3mo ago

If the solution was to remove an unused dependency, I think this CVE isn't silly at all.

realityking 3mo ago

IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.

inigyou 3mo ago
They should be in separate packages so you won't force yourself to patch CVEs in the parts you don't use?
delusional 3mo ago
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.
- gmueckl 3mo ago
  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.
  - TheDong 3mo ago
    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.
- 3mo ago

pico303 3mo ago

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.

SkyBelow 3mo ago

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?

pixl97 3mo ago
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.

vorticalbox 3mo ago

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 https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck

groundzeros2015 3mo ago

Also a buffer overflow in user space for a tool not serving internet traffic is not a big deal.

mandevil 3mo ago
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.
- groundzeros2015 3mo ago
  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.

sam_lowry_ 3mo ago

> our security policy required us Nope, someone should have requested that from you directly or indirectly, but you should not have done the pointless job if you have a pointy one usually. If you obey, it degrades you and the society at large.