> But that's exactly how real malware usually works. Individual components that are correct in isolation get combined in ways where the developer thinks that one component offers a guarantee that it doesn't really, and so some combination of inputs does something unexpected. An enterprising hacker exploits that to access the unexpected behavior.

That means there's a security vulnerability in the app and a bug in the library. Not a security vulnerability in the library.

IMO it's a mistake to assign CVEs to libraries

I would mostly agree, with the exception of libraries that are responsible for parsing untrusted input and making it safe. You can't, on the one hand, tell developers, "always validate your input, if not then we have a security vulnerability, and don't write your own validation libraries because they're super risky to get right", then pretend that the security hole caused by a bug in the library should have been handled properly in some fashion by developers.

And that is indeed the case here. The node-ip library had a security vulnerability in the function that informed developers if an IP was private or not. That's important when you accept user-defined webhooks and you want to ensure that an attacker isn't giving you something that resolves to a private IP within your own network. The whole process of "validating untrusted user input" ends up relying, at least in part, on libraries like this which tell you whether the components of the input are safe.

>The library developers push back and say "Can you point to one real-world vulnerability where the library is actually used in the way that the CVE says constitutes a vulnerability?"

From my understanding of the article, the developer suggested people provide not a "real-world vulnerability" but an example of one - a small project that exposes said vulnerability and steps one has to take to abuse it. And what he got irritated about was lack of such examples.

More so since he had been effectively email-DDoSed and had to chase some entity to mark the vulnerability as resolved, which probably took orders of magnitude more time, energy and soul from him, than actually fixing the bug.

But the _actual_ problem is the thanklessness (preferably material) of the work put into such open source projects, developer burnout and what not. Guy probably made like 1000$ total off of those millions of downloads per week. Understandably, he doesn't want his time being seemingly wasted discussing and fixing such seemingly unimportant issues.

Making open source materially rewarding and a more or less legitimate occupation is the real issue.

there's an example in the first reference link associated with the CVE: https://cosmosofcyberspace.github.io/npm_ip_cve/npm_ip_cve.h...

Granted, it's basically if(function_from_lib(user_input)) make_http_request(user_input) , which imo seems like a bit of a forced example, but it is an example

> effectively pushing the responsibility back onto the clients of the library.

That does not compute. The responsibility is pushed back onto the security researcher to prove that there is an actual vulnerability in practice.

Libraries (ideally) have documentation and contracts on what they expect on their input. If clients don't abide to the contract then it's on them. If the library has a wide contract then it's on the library. However even if the library has a bug, the bug needs to be exercised by clients for it to be an actually impactful vulnerability.

>effectively pushing the responsibility back onto the clients of the library.

well, yes. that's how this should work. if you want to use a library, it's up to you to decide whether or not it is a good fit for your project, including whether it has security issues that you need to worry about. a tool like NPM audit can help you make this decision, but there is no scenario where it makes a library developer responsible for fixing a security issue in your own project (unless you're paying them for that service).

Every library makes assumptions about the usage context. Stating those assumptions up front should be sufficient.

For example, Go has two differing template libraries: one for general text and one for HTML. They have very different assumptions about how you use them and what they protect against and those are stated in the documentation.

If we keep this idea in mind. Couldn't we argue that any piece of software that communicates over internet might allow any type of exploiting, including arbitrary code execution at Ring 0. As technically simple open socket could be made to input data directly to be executed by kernel process?

Indeed, and if that software can't point to some contract or license that suggests someone else is liable, then they are responsible.

Funnily enough, almost all open source projects not only disclaim such liability in very large print at the top of their licenses, but they don't even complicate the relationship with some kind of purchase agreement and renumeration.

They literally just say "Here's a thing. Use it if you want, change it if you want, but you're responsible for making sure it meets your requirements."

> Individual components that are correct in isolation

this point is wrong, and everything else following is consequently wrong as well.

This is an exemplary case where an individual component was correct under a very limited set conformance/correctness test. It is however wrong under the full set of conformance/correctness test.

So essentially, the component is incorrect in general and happens to be correct under the specific and most common cases.

Ugh - say I wrote a daemon that runs every 2 hours, it exposes no end points and has no metrics. But just because I depend on some library that brings in promethus which in turn brings some http2 library, I am on the hook for fixing this Cve in my code.

Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?

So much of security scanning is such bullshit.

> Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?

The problem is, from their viewpoint the security researcher is completely correct: a vulnerability is a vulnerability.

Consuming applications absolutely have to do their own research for CVEs in dependencies, to determine if they are impacted or not, and to develop mitigations on their side as well if needed.

> The problem is, from their viewpoint the security researcher is completely correct: a vulnerability is a vulnerability.

In the app using the library, not in the library.

Sure, but if you are using the library is there is no way to disclose vulnerabilities within libraries you have no idea if you need to implement mitigations or not.

There is no good solution here but not allowing CVEs to be assigned to libraries is by far the worst one.

Yeah, but that's exactly the problem. While the maintainer waits for that one real-world use case, others are hoarding the vuln or using it stealthily enough to not raise alarms.