95
Dev rejects CVE severity, makes his GitHub repo read-only
(www.bleepingcomputer.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Jun 2024
95 points (97.0% liked)
Technology
34892 readers
870 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
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.
It's interesting, that it would be hard to make a case that there was a "vulnerability" in the
ippackage. But it seems like this package's entire purpose is input validation so it's kind of weird the dev thinks otherwise.The researchers need to provide proofs of concept. Actual functional exploits.
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
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.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
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.
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.
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.