5 ms·

Reminds me of working on Chalk (JavaScript terminal coloring library). My first foray into "beg bounties" was with Chalk. We received a report that inputs that

by junon 1y ago

Reminds me of working on Chalk (JavaScript terminal coloring library). My first foray into "beg bounties" was with Chalk. We received a report that inputs that contained malicious terminal escape sequences would be emitted to the terminal if passed through chalk. But... yeah, of course they would. It's just a glorified string formatter, we don't care what you pass to us. They would have been emitted anyway if you just used console.log. There was literally nothing actionable for us to do. It wasn't our responsibility. It wasn't just left there. The "researcher" persisted, threatening to file a CVE (which wreaks havoc on an OSS dependency such as Chalk that has millions of downloads a day) and kept swinging their proverbial member around with how they work for soandso esteemed research company (it wasn't) and ultimately demanded we compensate for their time, citing it as a responsibility and obligation. I would have ignored it, but the threat of CVE (and the fact we'd have literally zero recourse against it) kept me on the hook. Ever since then it's really watered down my view of the CVE/CVSS systems and has turned me a bit bitter toward "security researchers" in general, which isn't where I'd like to be. With the rise of automatic ReDos detection the problem has only compounded over the last 4-5 years - things that might even technically fall under the "vulnerability" umbrella, but only if the code is so intentionally and egregiously misused, and in a manner that is dangerous with any library let alone ours, still earning a plea for monetary compensation. It's silly, saddening and only discourages people to work on OSS stuff at a scale larger than hobbies, to be honest. (Thank you for coming to my TED talk) EDIT: I should mention that I have received legitimate reports by well-meaning researchers (no quotes) that are detailed and professional in nature I'm always proud to service them and see them through. They're increasingly rare, though. The downside is that doing OSS for free means I still cannot compensate for their time, even though I would love to.

ahartmetz 1y ago
What are the consequences of a crap CVE with a vulnerability score of roughly 1 out of 10?
- SSLy 1y ago
  inbox / github issue spam
- junon 1y ago
  ReDos often get 7 or above since they can be "network accessible" (anything can be). CVSS is broken. And yes, people who get scared file reports asking us to fix it, oftentimes we can't (because it's not a real vuln), and 99% of the time they're not even remotely affected. The requests are generally not very nice, either. Most of the time, the request to fix a CVE is the first we've ever heard of it being filed. "Security research agencies" oftentimes have their own databases, and rarely do these "researchers" follow any amount of responsible disclosure, let alone even telling us about their findings or that they've filed. Many of them don't even cite a reporter, email, or any such contact information. Especially when the CVE is nonsense, improperly scored, etc. there is almost no way to get it taken down or to reduce its severity. Apparently in the eyes of these agencies the people writing the code cannot adequately gauge the severity of vulnerabilities. It's nearing levels of almost zero collaboration with maintainers before things are filed. I can't remember the last time I even had the opportunity to release a proper fix before a CVE went out. I can count on one hand the number of times I was asked before a CVE was filed. I don't think a single CVE of any code I maintain has had a score that properly reflected the severity of the actual vulnerability (assuming there even was one). Remember, most of us do this in free time, for free. So all of the extra bureaucracy and synthesized urgency can be extremely detrimental.
  - nrvn 1y ago
    you are not alone... https://socket.dev/blog/curl-project-and-go-security-teams-reject-cvss-as-broken https://socket.dev/blog/curl-project-and-go-security-teams-r... I believe there must be some "Murphy's law" or something with a name for that situation. When there is an established system and process there will be people geniunely using and it will work 100% for such people and bring value to all parties. And then there will be people "gaming the system" (for instance "security" "researchers" using CVE created by them as a personal or corporate KPI) and abusing other legitimate players. It is like patent trolls but better fortunately for us. Fortunately for all people of reason, the system itself gets patched. Maybe not in the best way possible but still. Two examples: - Openvex - this is my way as a project owner/developer/maintainer to declare that CVE-XXXX-YYYYY is false positive and why. - context-aware vulnerability scanning (or exploitability scanning) - govulncheck is a great example of that. You run and it says, module X has vulnerabilities Y and Z but you keep calm because we have not found any symbols in your codebase using it. I wish more scanners would adopt the second approach and projects like npm would greatly benefit from it. As you truly note you pick a random project and it will be 50% filled with ReDos or something that will be sitting in some nested dependency of eslint's dep tree that will never see the light of production environment's CPU. That being said, any vulnerability reporting and obtaining a CVE ID bypassing the project's security policies and responsible disclosure procedures must be prohibited. As a maintainer I want to know about a newly discovered vulnerability in my code to fix it and then the kind person that reported it to me can proceed to MITRE with the report in one hand and fixed version in the other.
klabb3 1y ago
Wow. On the other side of the table, for system owners it dilutes the meaning of CVEs and causes alarm fatigue. I have a friend who says his npm logs are full of scary CVE/security vulns that are not relevant. The cost of upgrading is high, often breaking changes due to average js package quality, and the only reason is to suppress a spurious warning. The thing security people refuse to accept though, is that security isn’t a paramount business concern, even if management understands the real risks. Stolen customer data is often followed by an apology and password reset request. Nobody cares, especially in a world where personal and private data no longer exists. Restore from backup, and move on. Should it be that way? No. But it is. It’s not a security or awareness problem, it’s a business/culture problem. You can’t fix a broken engine with a better taillight.
fc417fc802 1y ago
> threatening to file a CVE (which wreaks havoc on an OSS dependency such as Chalk that has millions of downloads a day) Why is that? If you aren't on payroll what leverage does anyone have over you here? Can't you quickly close all newly opened issues as WONTFIX with a copy-pasted link to the first one explaining the situation? Maybe I'm missing something but if I'm not being paid I really don't understand why I should care about something like this. If the people raising the issues are doing it as part of their job then this approach shifts the problem back to them - they can either coordinate among themselves to correct the CVE system or they can spend the time to explain the systemic failure to their manager. > I would have ignored it, but the threat of CVE (and the fact we'd have literally zero recourse against it) kept me on the hook. Why? If the person is truly making unreasonable demands then why would you expect anything you do to change the eventual outcome? They will do whatever they will do. Tell them their scam bit has failed on you, block them, and forget they exist.
- junon 1y ago
  Not CVE related directly but I had someone write a manifesto about how since I didn't implement a feature in `debug` that I'm a tyrant and that tyrants should be killed. All on GitHub. They live too close for comfort to me, geographically. Idk. Guess it's just not how I'd rather do GitHub interactions. I'd rather explain why, so that people who have hot heads are forced to be mad at the decision rather than me. It stems back to when I was on GitHub almost 15 years ago, and the culture it used to have, and not wanting to give that up. Could be a lost cause now, though.
  - fc417fc802 1y ago
    > I'd rather explain why I might have given you the wrong idea. I think it's important to explain why - exactly once. After that a link to that original explanation of what happened and why things are the way they are should suffice. The thing is, if someone isn't willing to follow that link and take the time to understand what's going on then presumably they aren't a reasonable individual. If that's the case then I estimate it's unlikely that engaging with them will lead anywhere useful. It's one thing if it's your manager or a teammate being unreasonable. But when it's a pseudonymous avatar with no financial or professional relationship to you that seems like all downsides and no upsides to me.

by junon 1y ago

ahartmetz 1y ago

What are the consequences of a crap CVE with a vulnerability score of roughly 1 out of 10?

SSLy 1y ago
inbox / github issue spam
junon 1y ago
ReDos often get 7 or above since they can be "network accessible" (anything can be). CVSS is broken. And yes, people who get scared file reports asking us to fix it, oftentimes we can't (because it's not a real vuln), and 99% of the time they're not even remotely affected. The requests are generally not very nice, either. Most of the time, the request to fix a CVE is the first we've ever heard of it being filed. "Security research agencies" oftentimes have their own databases, and rarely do these "researchers" follow any amount of responsible disclosure, let alone even telling us about their findings or that they've filed. Many of them don't even cite a reporter, email, or any such contact information. Especially when the CVE is nonsense, improperly scored, etc. there is almost no way to get it taken down or to reduce its severity. Apparently in the eyes of these agencies the people writing the code cannot adequately gauge the severity of vulnerabilities. It's nearing levels of almost zero collaboration with maintainers before things are filed. I can't remember the last time I even had the opportunity to release a proper fix before a CVE went out. I can count on one hand the number of times I was asked before a CVE was filed. I don't think a single CVE of any code I maintain has had a score that properly reflected the severity of the actual vulnerability (assuming there even was one). Remember, most of us do this in free time, for free. So all of the extra bureaucracy and synthesized urgency can be extremely detrimental.
- nrvn 1y ago
  you are not alone... https://socket.dev/blog/curl-project-and-go-security-teams-reject-cvss-as-broken https://socket.dev/blog/curl-project-and-go-security-teams-r... I believe there must be some "Murphy's law" or something with a name for that situation. When there is an established system and process there will be people geniunely using and it will work 100% for such people and bring value to all parties. And then there will be people "gaming the system" (for instance "security" "researchers" using CVE created by them as a personal or corporate KPI) and abusing other legitimate players. It is like patent trolls but better fortunately for us. Fortunately for all people of reason, the system itself gets patched. Maybe not in the best way possible but still. Two examples: - Openvex - this is my way as a project owner/developer/maintainer to declare that CVE-XXXX-YYYYY is false positive and why. - context-aware vulnerability scanning (or exploitability scanning) - govulncheck is a great example of that. You run and it says, module X has vulnerabilities Y and Z but you keep calm because we have not found any symbols in your codebase using it. I wish more scanners would adopt the second approach and projects like npm would greatly benefit from it. As you truly note you pick a random project and it will be 50% filled with ReDos or something that will be sitting in some nested dependency of eslint's dep tree that will never see the light of production environment's CPU. That being said, any vulnerability reporting and obtaining a CVE ID bypassing the project's security policies and responsible disclosure procedures must be prohibited. As a maintainer I want to know about a newly discovered vulnerability in my code to fix it and then the kind person that reported it to me can proceed to MITRE with the report in one hand and fixed version in the other.

klabb3 1y ago

Wow. On the other side of the table, for system owners it dilutes the meaning of CVEs and causes alarm fatigue. I have a friend who says his npm logs are full of scary CVE/security vulns that are not relevant. The cost of upgrading is high, often breaking changes due to average js package quality, and the only reason is to suppress a spurious warning. The thing security people refuse to accept though, is that security isn’t a paramount business concern, even if management understands the real risks. Stolen customer data is often followed by an apology and password reset request. Nobody cares, especially in a world where personal and private data no longer exists. Restore from backup, and move on. Should it be that way? No. But it is. It’s not a security or awareness problem, it’s a business/culture problem. You can’t fix a broken engine with a better taillight.

fc417fc802 1y ago

> threatening to file a CVE (which wreaks havoc on an OSS dependency such as Chalk that has millions of downloads a day) Why is that? If you aren't on payroll what leverage does anyone have over you here? Can't you quickly close all newly opened issues as WONTFIX with a copy-pasted link to the first one explaining the situation? Maybe I'm missing something but if I'm not being paid I really don't understand why I should care about something like this. If the people raising the issues are doing it as part of their job then this approach shifts the problem back to them - they can either coordinate among themselves to correct the CVE system or they can spend the time to explain the systemic failure to their manager. > I would have ignored it, but the threat of CVE (and the fact we'd have literally zero recourse against it) kept me on the hook. Why? If the person is truly making unreasonable demands then why would you expect anything you do to change the eventual outcome? They will do whatever they will do. Tell them their scam bit has failed on you, block them, and forget they exist.

junon 1y ago
Not CVE related directly but I had someone write a manifesto about how since I didn't implement a feature in `debug` that I'm a tyrant and that tyrants should be killed. All on GitHub. They live too close for comfort to me, geographically. Idk. Guess it's just not how I'd rather do GitHub interactions. I'd rather explain why, so that people who have hot heads are forced to be mad at the decision rather than me. It stems back to when I was on GitHub almost 15 years ago, and the culture it used to have, and not wanting to give that up. Could be a lost cause now, though.
- fc417fc802 1y ago
  > I'd rather explain why I might have given you the wrong idea. I think it's important to explain why - exactly once. After that a link to that original explanation of what happened and why things are the way they are should suffice. The thing is, if someone isn't willing to follow that link and take the time to understand what's going on then presumably they aren't a reasonable individual. If that's the case then I estimate it's unlikely that engaging with them will lead anywhere useful. It's one thing if it's your manager or a teammate being unreasonable. But when it's a pseudonymous avatar with no financial or professional relationship to you that seems like all downsides and no upsides to me.