•

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

https://www.bleepingcomputer.com/news/security/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.

6 comments

TheButtonJustSpins

•

Recurring incidents like these raise the question, how does one strike a balance?

Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.

On the flip side, would it be ethical if security practitioners, including novices, sat on what they thought was a security flaw—so as not to inconvenience the project maintainers?

This was already answered in the article: verify your security findings. Make a POC that actually exploits the vulnerability, then submit it with your report.

Pika

•

I think a good alternative is a CVE is assigned as somewhere between 1-3 unless proof of concept is able to be assigned, then and only then can the priority to increased to what it should be. these issue reports coming in as a 9 when you basically need to tell the program, "hey I'm being stupid just do it" in order for it to be vulnerable are only wasting developers time. I don't believe these issues should be ignored however I do think they should be quite a bit lower priority if no concept is provided.

onlinepersona

•

Well done. That dev doesn't have to put up with that shit. People still treat opensource devs like free labor, pressuring them as if they are entitled to a product. If an opensource project is important to you or your company, contribute in some way that doesn't pressure the dev, otherwise stfu.

Anti Commercial-AI license

JRaccoon

•

My main issue with CVEs nowadays is that it seems one gets generated even when 99% of the use cases for the software in question are not vulnerable as the vulnerability requires a very specific configuration/circumstances/etc. to be exploitable. In large projects with lots of dependencies this adds a lot of noice and there's a risk that actual important CVEs go unnoticed.

Phen

•

We get some concerned folks asking about vulnerabilities on our software all the time because some dependency has a critical vulnerability and that gets our stuff flagged as having critical vulnerabilities too, even tho you need to opt-in to that dependency in compile time and even when it's present it can only be abused by users with enough privilege to do directly much more than anything the vulnerability can end up doing.

alphapuggle

•

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.

This is a ridiculous expectation. Providing addresses in an unsupported format doesn't yield correct results? Who wouldda thunk it. Clean up your fucking code and pass it in as expected, or make your own damn node-ip.