Interesting 🤔 how #CVE are leveraged as resume items, putting #programmers #developers & project leads under pressure by #bogus CVE reports or unnecessary high CVE ratings.

Popular and obscure programs are affected in the #OpenSource #POSIX world e.g #Linux #freeBSD #netBSD #openBSD

#Curl âž° by #Daniel #Stenberg #IP by #Fedor #Indutny & #nodeIP are popular programs hit by this #phenomena which can lead to unwarranted #panic in the users space

https://www.bleepingcomputer.com/news/security/dev-rejects-cve-severity-makes-his-github-repo-read-only/

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

The popular open source project, 'ip' had its GitHub repository archived, or made "read-only" by its developer as a result of a dubious CVE report filed for his project. Unfortunately, open-source developers have recently been met with an uptick in debatable or outright bogus CVEs filed for their projects.

Fedor Indutny (@indutny@fosstodon.org)

There is something that have been bothering me for past few months, and resulted in me archiving node-ip repo on github: https://github.com/advisories/GHSA-78xj-cgh5-2h22 Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from `npm audit`. I just posted a comment on the advisory issue https://github.com/github/advisory-database/pull/3504#issuecomment-2189530624 asking to remove it, but looking at dicer's advisory https://github.com/advisories/GHSA-wm7h-9275-46v2 I see that there might be a larger pattern in place? /1

Fosstodon
Fedor Indutny (@indutny@fosstodon.org)

It looks like there are entities that in theory should fill the void in OSS community and provide resources for managing security reports for overloaded maintainers. (I'm looking at you SNYK) However, 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. /2

Fosstodon
Fedor Indutny (@indutny@fosstodon.org)

For that dicer bug in particular, I don't think it is reproducible as described in the advisory's PoC: https://gist.github.com/indutny-signal/9602403f5b0a946d139398e9bad8222c Furthermore the PoC doesn't seem to involve dicer at all: https://security.snyk.io/vuln/SNYK-JS-DICER-2311764 What's funny is that I found no way to dispute the advisory on SNYK. The closest thing that I found was to write a message to support, but I'm not entirely sure whether this results in a vulnerability takedown... /fin

Fosstodon
Fedor Indutny (@indutny@fosstodon.org)

Update: GitHub got back to me and decided to lower the vulnerability rating in response to my feedback. Furthermore, they advised me to enable Private Vulnerability Reporting feature so that I could get a chance at tackling the reports before they hit all package users next time. Great response! SNYK still didn't get back to me, though, and I have no idea if another feedback channel exists.

Fosstodon
@RadioAzureus "IP addresses supplied to it in a non-standard format" Note that, unlike IPv6, IPv4 has no "standard format". (People who deny this are requested to mention the RFC where it is standardized, along with the section number.)
@bortzmeyer @RadioAzureus this is the part where we argue the standard format is e.g. 2130706433 right?
@RadioAzureus Not that it takes away from the problem of bogus CVEs, but if one uses regular expressions to check IP address ranges, they're very much asking for problems. Just saying.