Dev rejects CVE severity, makes his GitHub repo read-only (www.bleepingcomputer.com)
from floofloof@lemmy.ca to technology@lemmy.ml on 30 Jun 2024 20:37
https://lemmy.ca/post/24152276

#technology

threaded - newest

rjek@feddit.uk on 30 Jun 2024 20:56 next collapse

node-ip not ip. If you’re just a Linux user don’t worry, it’s just some Node BS going down - again.

mesamunefire@lemmy.world on 30 Jun 2024 21:28 next collapse

I was about to say, if ip was read only…

lurch@sh.itjust.works on 01 Jul 2024 01:00 collapse

if it comes to that, we’ll just switch back to ifconfig etc

mesamunefire@lemmy.world on 01 Jul 2024 02:30 collapse

My muscle memory just finally got used to ip addr lol.

rammer@sopuli.xyz on 01 Jul 2024 15:04 collapse

Pro tip: ip a

progandy@feddit.de on 01 Jul 2024 05:38 next collapse

This sort of thing is the reason that the kernel has its own cve authority / cna now.

xavier666@lemm.ee on 01 Jul 2024 09:39 collapse

node-ip

I got 99 problems but node-js ain’t one

Godort@lemm.ee on 30 Jun 2024 21:18 next collapse

While many of the CVEs are filed in good faith by responsible researchers and represent credible security vulnerabilities, a recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly “collecting” CVEs to enrich their resume rather than reporting security bugs that constitute real-world, practical impact from exploitation.

Oh, this is once again HR’s fault

treadful@lemmy.zip on 30 Jun 2024 21:57 next collapse

Agree that people like to fluff the severity of bugs they report. It’s better for prestige and bounty payouts. But this is a little more nuanced.

“While I didn’t really intend the module to be used for any security related checks, I’m very curious how an untrusted input could end up being passed into ip.isPrivate or ip.isPublic [functions] and then used for verifying where the network connection came from.”

It’s interesting, that it would be hard to make a case that there was a “vulnerability” in the ip package. But it seems like this package’s entire purpose is input validation so it’s kind of weird the dev thinks otherwise.

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.

The researchers need to provide proofs of concept. Actual functional exploits.

progandy@feddit.de on 01 Jul 2024 05:33 next collapse

It’s interesting, that it would be hard to make a case that there was a “vulnerability” in the ip package. But it seems like this package’s entire purpose is input validation so it’s kind of weird the dev thinks otherwise.

Yes, input validation, probably for forms. What the Dev disputes is that he cannot see a case where it is used in a security critical way where

  1. the input format is unknown and
  2. it is essential to know if the IP is public or private.
SirQuackTheDuck@lemmy.world on 01 Jul 2024 09:09 collapse

Even worse, the CVE is effectively “if you use the package wrong, you get weird results”.

The affected method has signature function isPrivate(ip: string): boolean. Passing in a hex number is not a string, and a method (toString) exists for this.

scrubbles@poptalk.scrubbles.tech on 01 Jul 2024 05:33 next collapse

Yeah idk. I get what they’re saying completely, but this exact one seems easy. Just do a validation check and throw an error. I mean, it is an IP validator after all. Either support hex or don’t.

friendlymessage@feddit.de on 01 Jul 2024 16:18 collapse

The researchers need to provide proofs of concept. Actual functional exploits.

Talking in general, not for this very issue: In my experience, providing a proof of concept is often a lot harder than simply fixing the issue. For an open source project it’s probably more helpful if the reporter provides a fix or at least a recommendation on how to fix it

treadful@lemmy.zip on 01 Jul 2024 17:48 collapse

Even if you’re poking at a black box and are reporting that “it acts funny when I poke it this way.” I’m my opinion, a reporter should send along a script or at least explicit instructions on how to repro.

I take the report more serious since it demonstrates you have an understanding of the issue or exploit. It will also save my time and it’s likely a trivial effort for the reporter since they’ve the context and knowledge of the issue loaded up and ready to go.

friendlymessage@feddit.de on 01 Jul 2024 18:13 collapse

Yeah, I agree that any bug report on such a technical level should contain scripts or similar to reproduce the finding but that’s not the same as a full blown proof of concept exploit and I think to require an exploit sets the bar too high. A vulnerability is a vulnerability, no matter whether there’s an exploit or not. If you commission somebody to do a pentest you usually don’t get exploits either.

bl4kers@lemmy.ml on 01 Jul 2024 08:37 next collapse

Disputing a CVE is no straightforward task either, as a GitHub security team member explained. It requires a project maintainer to chase the CVE Numbering Authorities (CNA) that had originally issued the CVE.

CNAs have conventionally comprised NIST’s NVD and MITRE. Over the past few years, technology companies and security vendors joined the list and are also able to issue CVEs at will.

These seems like an issue worth addressing. If it’s too easy to report and too difficult to dispute, I could see the CVE ecosystem be weaponized and turned into a political tool.

johnyma22@lemmy.ml on 01 Jul 2024 16:39 collapse

Security related issues should go through responsible disclosure and it’s up to the maintainer to provide such a process or the recently flurry of “opportunistic whitehats” will continue to spam your issues and require triaging…

Github provides a process for this under the “Security” tab: github.com/ether/etherpad-lite/security as an example…

I find that by having a documented process it filters out a decent amount of time wasters.