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.
> 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.
That link is OK for the general concepts, but some of the details aren't quite right so read the license text if you are in a situation where the details matter. For example:
> 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.
> 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.
There are a couple of categories of ways to communicate that would not involve remote communications through a computer network.
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.
these don't seem to be the common cases that matter today - big corps taking open source code and making big money off them without giving anything back to the community and instead occasionally hound at lone developers for timely fixes so they can keep on making the big money.
I'd love an AGPL-ish license that's more like the LGPL. Only changes to the licensed code need to be opened, not anything linking against it, but they need to be opened even if the only distribution is by network access. And no need to send object files. Just a plain "if you modify my code, you MUST make your modifications publicly available".
My experience is that it’s not higher end commercial users who would actually harass the dev, but lower scale commercial users who don’t care and the license wouldn’t scare them off.
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.
Your first sentence is a little confusing, but I can confirm that Google, at least, uses lots of open source software, and the build system automatically checks that all the third-party libraries used in an executable have a suitable license. [1] They also vendor everything and will patch security issues locally.
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.
> Your first sentence is a little confusing, but I can confirm that Google, at least, uses lots of open source software, and the build system automatically checks that all the third-party libraries used in an executable have a suitable license. [1] They also vendor everything and will patch security issues locally.
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."
Yeah sorry I mixed up two thoughts but what I meant is that larger companies wouldn’t have engineers participating directly in this kind of behaviour. They’d check the license and stay away, or would have some formal process to participate and would know better than to harass a dev while representing a company.
Does Microsoft not have a clearance process though to make sure you’re not inadvertently leaking IP? For example contribution to an Apache 2.0 project takes with it patent grants.
I’m generally in favor of not trying very hard to get more users for open source software. More users means more problems. What’s in it for you?
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.”
> except that you can’t use it at work due to the license
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.
That's true, but it sounds rather informal. A risk-adverse company would probably want you to assign copyright formally. They need to know what they own and what they have a license for.
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’m wondering why maintainers of open source projects don’t register as CNAs with Mitre for their projects and also why they don’t file a dispute on the CVE with Mitre which is the source for NVD and GHSA. This would help eliminate or reduce the impact of frivolous CVEs.
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?
It may be, but perhaps there is some performance concern? I’m not familiar with this domain and application so it’s not clear to me whether the decisions made are sensible just from reading the code.
> It may be, but perhaps there is some performance concern?
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.
I concur. Any time I see tangles of regexes and if statements, it's going to be full of holes. I spent several months replacing messes like this with proper parsers and you'd be surprised at how many fuck ups fell out of the mess.
Parts of the code actually parses the IP strings into a sensible type (toBuffer). Why not use this representation for _all_ the queries and operations instead of mixing in regexes?
Regexes can be fine in order to parse the string representations initially. But for everything else I would stick with byte arrays etc.
"Impossible" to read? No. I didn't find it difficult to read at all. There are even comments that tell what the code is supposed to do, and tests that show how to use the functions. Are regular expressions "impossible" to read? Well maybe if someone doesn't understand regular expressions. There are a hundred million other ways to write these functions, sure, but if we wrote code to appease the personal tastes of every programmer in the world, we'd never get anything done.
> 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?
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.
I feel like the main reason someone uses a library like this is that they don't want to write or maintain such a regex. Don't tell me how the sausage is made!
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'?
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.
This doesn't seem like a fake CVE? I'm sympathetic to the maintainer, and I don't know that I would have acted any differently in his shoes, but the report correctly describes a possible scenario where the issue could defeat a SSRF check.
The score is mechanically calculated from the reported properties of the vulnerability, and heavily weights the breadth of possible attack vectors. That RCE vulnerability reports that the attacker must be adjacent to the targeted system; this one would be an 8.8 as well if it had that limitation.
the CVE for the node-ip requires also few special conditions - very uncommon format (never seen IP in hex anywhere), use of `isPublic` function (this lib has more functions), and even if this two conditions were meet, there is still one more condition - the ability to do SSRF. 9.8 score in this case is crazy.
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.
I don't think you're wrong, but it gets to the underlying question of what these systems are for. If you start from the perspective that you're going to patch all known CVEs, it doesn't seem like a big practical problem that this is 9.8 - it's unlikely your system is exposed, but equally unlikely you'd have a hard time upgrading node-ip. If you're not going to patch all known CVEs, CVSS scores aren't a useful guide to which ones are absolute must-fixes; Heartbleed was famously 5.0 when disclosed, and it's still only a 7.5 on the new scale.
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
Again, the score is mechanically calculated from specific features of the vulnerability, and the number of instances on the Internet which are exposed isn't one of those features.
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.
i only want the score to represent real threat, not what features it includes, as that is meaningless in the long run. i agree that it shouldn't include "i think is bad" as that is meaningless as well, the score should represent the threat, not the features.
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.
The article suggests that this DDoS is incentivized by the resume-padding cachet of having a CVE to your name, a kind of Hacktoberfest-style cobra effect:
> 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.
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."
> 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.
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.
Ha ha. The part that isn't being discussed how it is more profitable for certain commercial interests to have more vulnerabilities even if they are bogus.
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.
The recommendation of "blocking builds/deploys that contain high CVEs" is nonsense. It should be conditional on not having exactly the same CVE in what is already deployed, as it is blocking unrelated fixes.
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.
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?
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.
> effectively pushing the responsibility back onto the clients of the library.
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.
Ugh - say I wrote a daemon that runs every 2 hours, it exposes no end points and has no metrics. But just because I depend on some library that brings in promethus which in turn brings some http2 library, I am on the hook for fixing this Cve in my code.
Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?
> Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?
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.
Sure, but if you are using the library is there is no way to disclose vulnerabilities within libraries you have no idea if you need to implement mitigations or not.
There is no good solution here but not allowing CVEs to be assigned to libraries is by far the worst one.
> 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.
I 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.
>effectively pushing the responsibility back onto the clients of the library.
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).
Every library makes assumptions about the usage context. Stating those assumptions up front should be sufficient.
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.
If we keep this idea in mind. Couldn't we argue that any piece of software that communicates over internet might allow any type of exploiting, including arbitrary code execution at Ring 0. As technically simple open socket could be made to input data directly to be executed by kernel process?
Indeed, and if that software can't point to some contract or license that suggests someone else is liable, then they are responsible.
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."
>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?"
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
> Individual components that are correct in isolation
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.
Yeah, but that's exactly the problem. While the maintainer waits for that one real-world use case, others are hoarding the vuln or using it stealthily enough to not raise alarms.
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.
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.
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.
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.
Most of this behaviour comes from the desire by many companies to by compliant with a lot of security regulations. Which in many cases means silly rule like “you must run and action a security scanning system”. Because a lot of these scanners are just dumb wrappers running any piece of software that pretends to be a security scanner, and because the more rules does one have the more “valuable” it is, you end up with a race to scan the most. And that sadly translates into rules and reports like https://hackerone.com/reports/191220 - OPTIONS method can be used to check what methods does a web server accepts, therefore an attacker might use it to learn which methods to use for the attack. Except they can just try it with no effort. It’s this sort of “if you can see a lock then attacker will use that knowledge to know where the lock is” logic that must be followed by “let’s remove all locks so they cannot be attacked” response.
That's a very narrow view, to the point of being flat-out wrong. I was a CISO. Before that, I was a staff platform engineer who wrote the software other people would be evaluating.
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.
Yeah, they're risk analysts, not technologists. That's not inherently bad, you need those. In a previous life I worked in a domain with a lot of risk analysis, by the end I liked a lot of them and they were usually fairly easy to have as stakeholders. But security has a track record of failing to equip the rest of a business with process adequate for the inherent volatility in risk they're supposed to be managing. In the engine room it's still dashing from fire to fire, just with better fire alarms. The things you complain about are precisely the business problems that the security group should be solving. Cybersecurity is important enough that they can get away with overbearing demands without providing holistic solutions for the organization to reach them.
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.
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...
CI pipelines are worse than that. When a CI pipeline flags a vuln in a dependency it typically goes to the dev couched as a "defect" they need to remedy as part of their unrelated PR.
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)?
> 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.
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.
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.
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.
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.
108 comments
[ 5.2 ms ] story [ 203 ms ] thread(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?"
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 '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
https://github.com/indutny/node-ip
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...
- https://github.com/advisories?query=type%3Areviewed
- https://github.com/advisories/GHSA-ffmh-x56j-9rc3
> 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.
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.
> 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.
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.
https://cvss.js.org/
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.
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.
- 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.
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.
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.
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?
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.
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.
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.
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.