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 articleThe 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)
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 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 (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
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 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.
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...
Related
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 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 (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
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 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.