Dev rejects CVE severity, makes his GitHub repo read-only

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.

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?

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

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

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.

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

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.

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