Dev rejects CVE severity, makes his GitHub repo read-only
bleepingcomputer.com
bleepingcomputer.com
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.
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.
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.
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.
In the app using the library, not in the library.
There is no good solution here but not allowing CVEs to be assigned to libraries is by far the worst one.
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
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.
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).
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.
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."
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.
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
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.
(Personally I’ll keep licensing my stuff ISC, but I have the luxury of having near zero external attention on any of my open source stuff :p)
For example, IBM, the owner of Red Hat, forbids the use of GPL3 software on their equipment by their employees.
This I can understand. But the fact that they joined the witch-hunt for Stallman after the slandering piece by Selam Gano, who knowingly presented untrue statements as facts, and these were later picked up by mainstream media (some of these lies are still out there uncorrected[0]), that is still beyond me.
[0] Google for "Stallman defends Epstein", e.g. https://techcrunch.com/2019/09/16/computer-scientist-richard...
> The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
That's an overstatement. The requirement is that you make source available for your program is for "users interacting with it remotely through a computer network".
There are plenty of ways that you could let users communicate with a program on your server that do not involve remote communication through a computer network.
Could you give some examples?
One category is communication that is not through a computer network, such as through serial terminals or by voice.
Another category would be communication that is not remote. AGPL fails to define what it means by "interacting remotely", but where they use that phrase is in a section titled "Remote Network Interaction" which suggests they are using "remote" the way people generally use it in the context of networks. Remote in that context means generally not on the same LAN. If that's the case then while communication over the LAN would be over a computer network it would not be remote communication.
Any large company that would care about the license, would also have terms on their employees to not directly interact with projects and would likely internally patch it if needed instead.
It’s been a long time since I worked there, but I don’t know any reason that they wouldn’t send a patch upstream as well.
[1] https://docs.bazel.build/versions/0.24.0/be/functions.html#l...
I think that you and your parent agree, and that inserting an extra comma, marked by [,] below, would show this:
> My experience is that it’s not higher end commercial users[,] who would actually check the license, but lower scale commercial users who don’t care and the license wouldn’t scare them off.
That is, "higher-end commecial users would actually check the license, and are not engaging in this kind of behavior; lower-scale commercial users don't care about the license, and are engaging in this kind of behavior."
The trouble is that many software developers have jobs. It sucks to work on open source software that would be useful, except that you can’t use it at work due to the license. (Possibly at a future job.)
If you fully control the software then you can dual-license, but it’s a more difficult negotiation than “it’s yet another npm with a standard license.”
A lot of maintainers do it so they don't have to re-write everything when they change jobs. Those would generally agree with you.
Others do it for personal marketing or other economic purposes such as lock-in.
Then there are maintainers who just like doing open source work and like providing something useful for many.
Just to clarify:
If you hold the copyright over the code, you can change the license to whatever you want, whenever you want.
In other words, if you are the lone dev of a library that has been GPL for 20 years, and then you get hired, and you want to use that library at your job, you can just make a copy of it and say "this copy is yours to do with as you please, have fun". You don't even need to mess around with dual-licensing. Licenses affect only people who aren't the copyright holder.
Otherwise, the situation will be confusing when someone comes along years later. "Hmm, this code looks familiar. Wait, why do we have a copy of GPL-licensed code in our system, with the licenses removed?"
I never, not once, pushed an upstream dev to fix a thing. I provided plenty of PRs over the years. If they didn't get merged, we maintained our own locally patched version.
My job was to find a way for us all to do as little as possible to meet our security goals. Those goals were lofty and sometimes that turned out to require quite a bit of work. But we never, ever, made our problem someone else's problem.
You see the CISOs that are a pain in the ass. You don't see the ones quietly going about their business trying to make the world a little safer.
Seems impossible to read and verify. Wouldn’t it be simpler and more consistent to have a first parse the IP into an internal format then perform all logic on that?
I'm skeptical of that concern: executing multiple regular expression matches on a string is never going to be faster than parsing the entire string once, into a 4-octet structure, and then performing integer comparisons on the octets.
Regexes can be fine in order to parse the string representations initially. But for everything else I would stick with byte arrays etc.
So not speaking about this library specifically but yes, separating the address parsing part (https://www.netmeister.org/blog/inet_aton.html is a fun read) from the "is this address considered private?" part should make things much simpler.
Vast majority of related code in this space that I've seen works like that. I'm actually struggling to come up with counterexamples.
> the verification process of vulnerability reports doesn't involve maintainer at all, and it sounds like the commercial interest of advisory repositories is aligned with creating more vulnerabilities and proving themselves “useful" to companies that utilize them.
That's exactly the problem: they use automated vulnerability scanners and AI to "find" these vulnerabilities, flooding the system with useless reports.
In the end it's quite clear that more verification and a trusted mediator is needed in this system.
> The 'node-ip' project exists on the npmjs.com registry as the 'ip' package
> The popular open source project, 'ip' recently had its GitHub repository archived
While many of the CVEs are filed in good faith ... a recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly "collecting" CVEs to enrich their resume
The potential downward spiral: Projects that receive an inappropriate CVE get defended by their devs.
Some devs have more success at this. Their language and methods are parroted by unscrupulous actors - like entities who buy/usurp control of a repository for malicious means.
If we get here, the likely outcomes seem to be:
1) CVE reporting authorities recognize the problem and tighten up reporting procedures (to mostly good ends) or
2) The people who properly depend on CVEs become increasingly exhausted trying to validate their integrity; they devalue and depend on them less. This further accelerates CVE's lack of trustworthiness and gives bad actors wider room to operate.
- Rude - Counterproductive - not going to result in a fix - not going to help users
If someone does that in the full knowledge that it will cause a DoS on inocent party's build processes and their ability to shift fixes. It could be validly considered a deliberate denial of service via a supply chain attack.
Maybe that should be policy, so these security bods are forced to accept responsibility for the work they cause.
That would look good on their CVs.
The solution therefore is to blindly accept any PRs from white knights that show up around the same time an obscure edge case CVE is reported. As the CVE reporting process teaches us, always accept unauthenticated input as valid without regard to how this impacts other people's lives.
Maybe we should start expecting accompanying patches as a “proof of work” scheme for CVEs?
I understand that finding vulnerabilities is a different skillset than fixing them, but as Offensive Security says: “Try Harder”
https://github.com/github/advisory-database/pull/3504#issuec...
It’s “who”, not “whom”, in this case. The “who” is in the nominative case here, i.e. it is the subject of the clause, not the object.
A good way to make developers not care about CVEs, and therefore allow attackers to introduce real vulnerabilities, is to post lots of fake CVEs so nobody pays attention.
However, the severity score of 9.8 [1]
Whereas a remotely exploitable remote code execution bug in a windows wifi driver only scores 8.8 [2]
So the score seems very inflated to me.
[1] https://nvd.nist.gov/vuln/detail/CVE-2023-42282 [2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
don't get me wrong, it is an issue, but not critical, making everything critical, for frontend libs on npm creates fatigue and nobody takes these scores seriously anymore. in case of real issue, nobody will care enough to patch it, as everything is critical.
the difference: you can find affected openssh servers, with the node-ip issue you have to find very rare instance that would allow for SSRF and create exploit for the exact use case. with openssh you can make it really broad.
so the 9.8 score for node-ip is crazy high, and nobody should question it, it should be ~6 max
I would agree that the CVSS is not, in this instance, measuring something particularly related to the practical importance of the vulnerability. I agree nobody can really dispute that. But does that mean that the next version of CVSS should include "I bet not many systems are exposed" or "I subjectively think this isn't that bad" dimensions? I'm skeptical - that seems like it would create more problems than it solves.
because i'm checking dependabot [0][1] regularly, there is a lot of issues with very high scores for frontend libraries, that have really low impact, because it "checks" some features. eg some plugin for jquery (frontend lib) [2] that has the same score as heartbleed, which is insane and shows how useless the score is in current form.
- https://docs.github.com/en/code-security/dependabot/dependab...
> a recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly "collecting" CVEs to enrich their resume
Naturally, such a reporter would value higher severity reports.
I haven't really thought that much about the CVE process. It's kind of strange to me that Github, Snyk, and the NVD may all have different evaluations of a report. I guess decentralization is a feature, but one not without bugs.
All of the popular open source licenses, GPL, MIT and BSD, quite plainly state that, to the extent permissible by law, there is no warranty about anything, whatsoever.
There was a time when Linux users (in general) understood this. You want free? You pick any distribution you like. You want a warranty? You pick RedHat.
But over time, it seems we've gotten to a point where "I imported your package, so that means you're obliged not to break my precious CI" has somehow become the norm.
This is bad for open source, and, frankly, bad for everyone, and I think it's high time that people start taking responsibility for their dependencies, either by paying for support, or by maintaining their own bugfix branches...
Left entirely out of the consciousness horizon is the realization that the code is almost certainly <<running in production right now>>. Where is the check that it hasn't been exploited, or concerning what the attack surface is in the product (or even if continuing to embrace the dependency is worth the hassle)?
Where is SecOps?
https://github.com/indutny/node-ip/issues/136
The stupidity is like a cancer that spreads and infects random other repositories with alarmist nonsense:
https://github.com/JoshGlazebrook/socks/issues/93#issue-2128...
"I didn't look through the code" yeah no shit sherlock, you didn't look through code in a while.
The underlying issue here is that there are many libraries that a supported by solo devs like this. An idea I just had is that it would be reasonable to calculate a risk metric for every package in the various eco-systems that takes repo maintainer count (and other things) into consideration. Publishing this metric into the package metadata / package page on npmjs would probably gamify not having single points of failure in widely used libraries, and make it clear when this is happening at some point in your dependency chain (averting a future left-pad style debacle).
If you're an authoritative entity over a system (CVEs) that can break production systems (and to be clear, NIST recommends blocking builds/deploys that contain high CVEs), then it's also on you to make sure you're not issuing bogus CVEs.
There is something wrong with security industry and we are all paying the price. At my day job some tool automatically opens security bugs against 15 or so repos we maintain and now we are on the hook for arguing how the report was bogus or fix the vulnerability. Just PR and Jira dance one has to do is exhausting.
It's concerning because you don't want to become insensitive to security reports, but also some of the proposed fixes involve security sensitive project setup and this could be an avenue for exfiltrating secrets.
This situation gives reproducability-crisis vibes, where people are submitting junk research for some external reward. security is particularly vulnerable to garbage research, and this is a recipe for fraud. perhaps the hacker mindset is earnest and quaint compared to the layered deceptions of academic dishonesty.
The chief complaint was him getting tons of issues/PRs about _old_ versions of the library that still contained the bug.
Knowing this now, I can understand why they decided to archive the thing.
I still stand by package management being a huge problem within Node that just encourages shit like this to happen.
---
OLD POST: From one of the sources [0] of the CVE:
> Root Cause:
> The root cause of this vulnerability is the ip.isPublic function's inability to correctly interpret and classify certain IP address representations.
> Specifically, the function fails to recognize 0x7f.1 as a private IP address, which is actually a hexadecimal and shorthand notation for 127.0.0.1, a well-known loopback address.
> This misinterpretation leads to the function erroneously categorizing a private IP as public, thereby opening up the potential for Server-Side Request Forgery (SSRF) attacks. The core issue lies in the inadequate handling of non-standard IP address formats by the IP address validation mechanism.
It then goes on to demonstrate that "ip.isPublic" would classify "0xf.1" as "globally-routable" 127.0.0.1.
So instead of patching this very obviously huge security vulnerability in a package that has been downloaded 17 MILLION TIMES, the maintainer decides "screw it" and abandons the repo.
(The PortSwigger academy has a course on SSRF, and their labs let you fool around with some exfiltration/remote code execution scenarios triggered by a PHP module doing essentially the same thing this CVE is warning about.)
While someone will, of course, fork this project and provide a fix that others can reference in their "package.json" manifests, hoards of projects will probably see downtime due to security forcing them to scale down and fix this.
While this can, for sure, happen with other languages (like how the requests module in Python had a serious vulnerability some time back), this risk is exponentially worse with Node since JavaScript doesn't really have a stdlib and every little thing (like a timer [1]) is just painful enough to make downloading some arbitrary library attractive.
[0] https://cosmosofcyberspace.github.io/npm_ip_cve/npm_ip_cve.h...
[1] https://stackoverflow.com/questions/29971898/how-to-create-a...
> The CVE has to do with the utility not correctly identifying private IP addresses supplied to it in a non-standard format, such as hexadecimal. This would cause the 'node-ip' utility to treat a private IP address (in hex format) such as " 0x7F.1..." (which represents 127.1...) as public.
Things aren't necessarily as simple as they appear.
There's this thing called IANA IPv4 Special-Purpose Address Registry[1] and it lists some address ranges labeled Private-Use, it's the usual suspects: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
The table also has a Globally Reachable column. Some special ranges, including but not limited to Private-Use above, have Globally Reachable set to false.
Some others, like Direct Delegation AS112 Service (I don't know what it actually is), are listed as actually Globally Reachable.
So I'd say there are at least three plausible interpretation of the word "private" in this context:
1. IPv4 or IPv6 address, listed as a special range and Globally Reachable = false (caveat: for some IPv6 ranges there can be N/A in that column[2], more choices to make) 2. These IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 3. All special ranges from [1] and [2], we don't want to try to contact any of these
For example Python's ipaddress mostly follows interpretation 1 while Rust standard library[3] and Python's netaddr[4] (disclosure: I maintain it) effectively follow interpretation 2.
From the point of view of a library author the semantics of what's private, what's public, global, etc. needs to be documented very well and examples provided.
From the point of view of a library user the documentation needs to be consulted (and tests performed) to make sure the library semantics match assumptions/expectations.
It all gets complicated rather quickly.
[1] https://www.iana.org/assignments/iana-ipv4-special-registry/... [2] https://www.iana.org/assignments/iana-ipv6-special-registry/... [3] https://doc.rust-lang.org/std/net/struct.Ipv4Addr.html#metho... [4] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IP...