4 ms·

There's an interesting point hiding in the article about security being an emergent property of the whole software system. Many libraries are flagged with CVEs

There's an interesting point hiding in the article about security being an emergent property of the whole software system. Many libraries are flagged with CVEs because they can be used as part of the trust boundary of the whole software system, and they have corner cases that allow certain malicious inputs to give outputs that may be surprising and unexpected to the clients of the library. 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?", effectively pushing the responsibility back onto the clients of the library. 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. There isn't really a good solution here, but it seems like understanding this tradeoff would point research toward topics like proof-carrying code, fuzzing, trust boundaries, capabilities, simplifying your system, and other whole-system approaches to security rather than nitpicking individual libraries for potential security vulnerabilities.

Ekaros 2y ago
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?
- swatcoder 2y ago
  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."
alx_the_new_guy 2y ago
>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.
- nickitolas 2y ago
  there's an example in the first reference link associated with the CVE: https://cosmosofcyberspace.github.io/npm_ip_cve/npm_ip_cve.html 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
znpy 2y ago
> 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.
nunez 2y ago
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.
leni536 2y ago
> 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.
philipwhiuk 2y ago
> 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
- solatic 2y ago
  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.
notatoad 2y ago
>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).
throwaway_62022 2y ago
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.
- mschuster91 2y ago
  > 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.
  - philipwhiuk 2y ago
    > 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.
    - dogma1138 2y ago
      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.
dgb23 2y ago
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.

Ekaros 2y ago

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?

swatcoder 2y ago
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."

alx_the_new_guy 2y ago

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

nickitolas 2y ago
there's an example in the first reference link associated with the CVE: https://cosmosofcyberspace.github.io/npm_ip_cve/npm_ip_cve.html 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

znpy 2y ago

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

nunez 2y ago

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.

leni536 2y ago

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

philipwhiuk 2y ago

> 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

solatic 2y ago
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.

notatoad 2y ago

>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).

throwaway_62022 2y ago

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.

mschuster91 2y ago
> 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.
- philipwhiuk 2y ago
  > 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.
  - dogma1138 2y ago
    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.

dgb23 2y ago

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.