June 30th, 2024

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

The 'ip' project's developer, Fedor Indutny, made the GitHub repository read-only due to a disputed CVE report (CVE-2023-42282) about 'node-ip' misidentifying private IP addresses. This incident underscores challenges with inexperienced CVE filings.

Read original articleLink Icon
Dev rejects CVE severity, makes his GitHub repo read-only

The developer of the 'ip' open-source project, Fedor Indutny, made his GitHub repository read-only after receiving a controversial CVE report. This action was taken due to an increase in questionable or false CVE reports filed against open-source projects, causing unnecessary concern and disruptions for developers and users. The specific issue, CVE-2023-42282, involved a vulnerability related to the 'node-ip' utility incorrectly identifying private IP addresses in non-standard formats. Despite fixing the bug, Indutny disputed the severity of the vulnerability, leading to a debate with GitHub and the CVE Numbering Authorities. This incident reflects a growing trend of inexperienced security enthusiasts filing CVEs for resume-building purposes rather than addressing real security threats. The situation highlights the challenges faced by developers in managing unverified vulnerability reports and the need for a balanced approach to reporting and addressing security issues in open-source projects.

Related

Arbitrary shell command evaluation in Org Mode (GNU Emacs)

Arbitrary shell command evaluation in Org Mode (GNU Emacs)

A vulnerability in Emacs Org mode allowed arbitrary shell command execution. A fix in Emacs 29.4 and Org 9.7.5 prevents unsafe code evaluation in link abbreviations, advising users to apply the patch.

Reputation Farming Using Closed GitHub Issues

Reputation Farming Using Closed GitHub Issues

Reputation farming on GitHub involves manipulating closed issues and pull requests to falsely boost accounts' reputation. Maintainers are urged to monitor activity, report suspicious behavior, and automate checks to prevent this deceptive practice.

The Dirty Pipe Vulnerability

The Dirty Pipe Vulnerability

The Dirty Pipe Vulnerability (CVE-2022-0847) in Linux kernel versions since 5.8 allowed unauthorized data overwriting in read-only files, fixed in versions 5.16.11, 5.15.25, and 5.10.102. Discovered through CRC errors in log files, it revealed systematic corruption linked to ZIP file headers due to a kernel bug in Linux 5.10. The bug's origin was pinpointed by replicating data transfer issues between processes using C programs, exposing the faulty commit. Changes in the pipe buffer code impacted data transfer efficiency, emphasizing the intricate nature of kernel development and software component interactions.

CVE-2021-4440: A Linux CNA Case Study

CVE-2021-4440: A Linux CNA Case Study

The Linux CNA mishandled CVE-2021-4440 in the 5.10 LTS kernel, causing information leakage and KASLR defeats. The issue affected Debian Bullseye and SUSE's 5.3.18 kernel, resolved in version 5.10.218.

The weirdest QNX bug I've ever encountered

The weirdest QNX bug I've ever encountered

The author encountered a CPU usage bug in a QNX system's 'ps' utility due to a 15-year-old bug. Debugging revealed a race condition, leading to code modifications and a shift towards open-source solutions.

Link Icon 31 comments
By @nostrademons - 5 months
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.

By @kibwen - 5 months
My predisposition is that the people hounding open-source devs for unpaid urgent tech support are predominantly commercial users freeloading off the software, which, amusingly, means that a compelling argument in favor of licensing your software as GPL is to scare away these sorts of users.
By @pheatherlite - 5 months
CISO and people in his office (the so-called cyber security experts) are nothing but report pushers. They run vulnerability scans on code, and whatever comes back from packages like Tenable, they send to everyone to justify their own existence. They don't consider the severity, they don't consider snd differentiate between attack surfaces and attack vectors. They just hound you and your superiors in the name of insurance liabilities... they suck. They turn developers into hounds that harass other developers for fixes. Out goes the desire to work on a software because all you're doing is patching nonsense every day because some ciso somewhere is unsatisfied. To hell with each and every ciso. Security is important and having cyber folks that have programming background is even more important. Mindless lemmings otherwise.
By @jey - 5 months
At first blush based on the patch to fix this bug, I’d say the code looks terrible: https://github.com/indutny/node-ip/commit/32f468f1245574785e...

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?

By @betaby - 5 months
Most of the CVEs I have to deal on my $DAY_JOB are regular bugs, not security issues. Nowadays CVEs are like bitcoin mining but for the security folks.
By @29athrowaway - 5 months
The package author has a point

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

By @delusional - 5 months
It seems absolutely insane that this would get anywhere near a 9.8 severity considering that the windows RCE over wifi scored 9.8 as well. Who makes these scores?
By @hnthrowaway0328 - 5 months
This kind of things might be the first step of a hostile takeover: push the developer to make some changes quickly and then offer help.
By @tamimio - 5 months
> recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly "collecting" CVEs to enrich their resume

That's exactly the problem: they use automated vulnerability scanners and AI to "find" these vulnerabilities, flooding the system with useless reports.

By @mort96 - 5 months
Wait is this about 'ip', the command from iproute2, or 'node-ip', some node.js library? Both? Why does one part of this article say 'ip' and another 'node-ip'?
By @WarOnPrivacy - 5 months
The CVE system...has lately attracted a segment of community members filing unverified 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.

By @paiute - 5 months
The CVE industrial complex is real. The majority of CVE I’ve looked into are not really risks. It’s a sea of noise with the occasional super important exception. Good an on this dev.
By @teknopaul - 5 months
If the devs indicate that they aren't going to fix it, raising a cve is

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

By @hermannj314 - 5 months
If the CVE pipeline has decided to blindly trust anyone who puts information into their system, then the only sustainable system is for the downstream processes to do the same thing.

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.

By @r3trohack3r - 5 months
Reading this article I’m left wondering why it’s considered socially acceptable for a security researcher to frequently open reports against open source software projects without accompanying those reports with a diff fixing the vulnerability?

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”

By @proactivesvcs - 5 months
From someone who I think works for GitHub: "We think that GHSA-78xj-cgh5-2h22 still has potential, albeit low, security impact. We believe it makes sense to keep the advisory but to lower the severity to low."

https://github.com/github/advisory-database/pull/3504#issuec...

By @lowbloodsugar - 5 months
TL;DR The CVE system has no authentication mechanism (to determine the authenticity of reported “bugs” or verify their reported level) resulting in a DDOS of maintainers.

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.

By @cratermoon - 5 months
Having your name on a severe CVE is the new having your name on a patent. The incentives are set up not to improve security, but to generate reports. Companies will pay bounties to their employees for finding CVEs, even if they aren't the owners of the code. Result: thousands of meaningless CVEs that drown out real security issue in the noise.
By @PreInternet01 - 5 months
I think people should take a step back here, and meditate a bit on what "disclaimer of warranty" means.

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

By @icetank - 5 months
I remember a Node.js library I worked on completely broke after a Node.js security update disabled a encyption feature. I don't think anyone could come up with a tangible exploit chain but the Node.js maintainers made the breaking change anyway because of the CVE. There was maybe one guy bringing attention to the CVE and 20 or so more people complaining about broken production applications. I wonder at what point people give up on CVE notices and just don't update for security patches when the majority of CVE reports are bogus anyway. I know the Node.js library we work with had about 10 security notices on npm audit. But none of them compromise the libraries security in any way. People still try to remedy them with npm audit fix but that just causes there dependencies to break completely.
By @joshka - 5 months
If I was getting spam from devs to fix a thing in a library like this, my response would be "sure, here's my rate $/h". This seems like a pretty fair put up or shut up response.

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

By @ang_cire - 5 months
Frankly, the end of the article where it says that CNAs don't have the time to verify the vulns being reported for new CVE issuance, is the real problem.

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.

By @skybrian - 5 months
By @mmastrac - 5 months
I tried fighting a bogus CVE earlier on one of my libraries and it's impossible. GitHub doesn't care, there's no higher power to report them to.
By @spankalee - 5 months
We've had a few dubious or outright indirect GitHub security advisories opened by people obviously trying to boost their resume or push their automated scanning tools.

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.

By @tmsh - 5 months
It seems like there should be some authority weight baked into CVEs based on history or upvotes from credible companies (with higher authority). Need some tree structure to manage the growing scale.
By @motohagiography - 5 months
are there incentives where the credit for "discovering" a CVE is greater than the reputational consequences of reporting a false one?

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.

By @booleandilemma - 5 months
Good for him.
By @nunez - 5 months
I wrote a wall of text earlier. Some of my opinion was misinformed. The dev patched this bug when it was disclosed in 2022.

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

By @jstasiak - 5 months
Tangential, but thought I'd mention this

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