4 ms·
> 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 on
by 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 agoI 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.