Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE Stuffing

jerrygamblin.com

Post reply on HN
Print view View original

51–60 of 108 posts

Re: CVE Stuffing

#51

Post by seanwilson »

arp242 wrote: post #34
seanwilson wrote: post #26

Earlier quoted context omitted.

> Apparently because my site didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me. There's no good reason that folder should exist except for a joke, so how is this not a helpful message in the vast majority of cases? All lint rules have exceptions, doesn't make them not useful.

I didn't ask you to lint my code (or server) though. There's plenty of cases where a .git directory is just harmless; I've deployed simple static sites by just cloning the repo, and this probably exposed the .git directory. But who cares? There's nothing in there that's secret, and it's just the same as what you would get from the public GitHub repo, so whatever. That some linting tools warns on this: sure, that's re…

> That some linting tools warns on this: sure, that's reasonable.

To clarify, I'm not condoning annoying spam but if say e.g. Netlify or GitHub added a ".git folder should not exist on a public site" lint rule when you personally deploy your site, I would say it would be a net benefit.

> There's plenty of cases where a .git directory is just harmless

Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule.

Re: CVE Stuffing

#52

Post by hoppla »

sanxiyn wrote: post #3
brohee wrote: post #2

Didn't check who filled those bugs, but I've seen companies requiring having discovered CVE to apply for some jobs, and the natural consequence is gaming the system...

I checked, it seems to be a student of Seoul National University, South Korea. https://github.com/donghyunlee00/CVE

A second guy is also doing this. CVEs have a reference to third party advisories such as https://github.com/koharin/koharin2/blob/main/CVE-2020-35185

This repository does no longer exists.

Re: CVE Stuffing

#53

Post by Kalium »

seanwilson wrote: post #51
arp242 wrote: post #34

Earlier quoted context omitted.

I didn't ask you to lint my code (or server) though. There's plenty of cases where a .git directory is just harmless; I've deployed simple static sites by just cloning the repo, and this probably exposed the .git directory. But who cares? There's nothing in there that's secret, and it's just the same as what you would get from the public GitHub repo, so whatever. That some linting tools warns on this: sure, that's re…

> That some linting tools warns on this: sure, that's reasonable. To clarify, I'm not condoning annoying spam but if say e.g. Netlify or GitHub added a ".git folder should not exist on a public site" lint rule when you personally deploy your site, I would say it would be a net benefit. > There's plenty of cases where a .git directory is just harmless Pretty much all lint rules have false positives so this isn't a goo…

> Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule.

A responsible person running such a linter does a sanity check before taking their positive and bugging someone else with it. An irresponsible one potentially causes harm by assuming every single hit is a major finding that should turn into a bounty payout.

Re: CVE Stuffing

#55

Post by Macha »

raverbashing wrote: post #19
bregma wrote: post #6

I'm a command-line development tools maintainer for an OS. I am not unfamiliar with high-level CVEs in my inbox with the likes of "gdb crashes on a handcrafted core file causing a DoS". I am unfamiliar with a real world in which a simple old-fashioned segfault in a crash analysis tool is truly a denial of service security vulnerability, but our security department assures us we need to drop all revenue work and rush…

Ah yes, this also fits with the famous "no insecure algorithms" in which an auditor will check a box if your use md5, even if for a feature totally unrelated to security.

Our security team at a previous employer previously added a systemwide checker to our github enterprise installation that would spam comments on any change to a file in which Math.random is used. The idea is that anyone using random numbers must be implementing a cryptographic protocol and therefore should not be using Math.random as it's not a CSPRNG.

So all the AB tests, percentage rollouts etc. started getting spam PR comments until they were made to turn it back off again.

Frankly if a teammate was writing their own crypto algorithm implemntation in the bog standard web app we working on, that would be more concerning than which RNG they're using.

Re: CVE Stuffing

#56

Post by seanwilson »

Kalium wrote: post #53
seanwilson wrote: post #51

Earlier quoted context omitted.

> That some linting tools warns on this: sure, that's reasonable. To clarify, I'm not condoning annoying spam but if say e.g. Netlify or GitHub added a ".git folder should not exist on a public site" lint rule when you personally deploy your site, I would say it would be a net benefit. > There's plenty of cases where a .git directory is just harmless Pretty much all lint rules have false positives so this isn't a goo…

> Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule. A responsible person running such a linter does a sanity check before taking their positive and bugging someone else with it. An irresponsible one potentially causes harm by assuming eve…

> A responsible person running such a linter does a sanity check before taking their positive and bugging someone else with it. An irresponsible one potentially causes harm by assuming every single hit is a major finding that should turn into a bounty payout.

I already tried to clarify that I was talking about the general concept of good lint rules, not about people emailing for bounty payouts. We're in agreement that emails about bounty payouts for non-issues is stupid.

Re: CVE Stuffing

#57

Post by belval »

jart wrote: post #15

I remember when people in the security community started filing CVEs against the TensorFlow project, claiming that code execution was possible with a handcrafted TensorFlow graph, and the team would have to try and explain, "TensorFlow GraphDefs are code".

The whole situation around CVE in Tensorflow is very painful, you get GitHub security notifications for any public repository using TF because of a "known CVE", even though it's basically just a train.py script that is not deployed anywhere.

Re: CVE Stuffing

#58

Post by [deleted] »

easterncalculus wrote: post #36

Lots of CVEs are illegitimate. You have people creating whole "vulnerabilities" that are just long known features of various technologies. The worst one I'm remembering is the "discovery" of "Zip Slip" and "ZipperDown", which were both just gotchas in the zip format that have been known about for decades now. Both got trendy websites just like Spectre and Meltdown, and loads of headlines. ZipperDown.org is now an onl…

[deleted]

Re: CVE Stuffing

#59

Post by smsm42 »

jebronie wrote: post #54

A security auditor once reported a Adobe generator comment in an SVG file as a moderate "version leak vulnerability" to me.

This is a staple of audit report stuffing. Somebody got an idea that disclosing a version of anything anywhere is a huge security hole, so now any publicly visible version string generates a "moderate" (they are usually not as brazen as to call it "critical") security report.

Re: CVE Stuffing

#60

Post by smsm42 »

I feel this is the consequence of paying people for security bugs reporting (and only security bugs reporting). People start to inflate the number of reports and no longer care about proper severity assignment as long as it get them that coveted "security bug" checkbox. I mean I can see how bounty programs and projects like hackerone can be beneficial, but this is one of the downsides of it.

CNA system actually is better since it at least puts some filter on it - before it was Wild West, anybody could assign CVE to any issue in any product without any feedback from anybody knowledgeable in the code base and assign any severity they liked, which led to wildly misleading reports. I think CNA at least provides some sourcing information and order to it.

Post reply on HN