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

61–70 of 108 posts

Re: CVE Stuffing

#61

Post by hoppla »

beardedwizard wrote: post #14
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…

Maybe you can get on the phone with your customers, their security teams, and their compliance teams and explain every single day why these known vulnerabilities are not serious and can never be leveraged. You can convince them all of these latent bugs will never pose a serious risk. You can do this all day every day. Or you can just patch, and maintain a capability to do so quickly because bugs don't just affect sec…

It will probably be less effort to patch (increment version number) a non existing vulnerability than to explain it to every customer that comes with an report from a third party auditor.

CVEs for non-vulnerabilities is like corporate trolling

Re: CVE Stuffing

#62

Post by bostik »

Shank wrote: post #43
MrStonedOne wrote: post #5

Way back when I saw a report on hackernews about secret exposure from websites that deployed directly via a git repo as a webroot and didn't block access to .git/ I added a cheeky message to my site's .git/ folder if you attempted to view it. About 2 or 3 months later I started getting "security reports" to the catch all, about an exposed git folder that was leaking my website's secrets. Apparently because my site di…

This is quite common. If you run a security@ mailbox at a company, you're bound to receive hundreds of bug bounty/responsible disclosure requests because of known software quirks or other design choices. They'll cite precisely one CVE or HackerOne/BugCrowd report, and then proceed to demand a huge payment for a critical security flaw. I've seen reports that easily fail the airtight hatchway [0] tests in a variety of…

Yup, according to these "researchers" having robots.txt on your website is enough to warrant a CRITICAL vulnerability.

No, I'm not joking. That's one of the reports I saw in November. I've also had to triage the claim that our site supposedly has a gazillion *.tar.xz files available at the root. All because the 404 handler for random [non-production relevant] paths is a fixed page with 200 response.

As far as I'm concerned, running a bulk vulnerability scanner against a website and not even checking the results has as much to do with security research as ripping wings off of flies has to do with bioengineering.

Re: CVE Stuffing

#63

Post by eyeareque »

Mitre is a us gov supported team, and previously they could not scale to the need of their efforts. They did the best they could, but they still had a lot of angry people out there. The whole world uses CVEs but it is US funded by the way.

In come new CNAs, scale the efforts through trusted teams, which makes sense. The mitre team can only do so much on their own.

Unfortunately I don’t think anyone will be as strict and passionate about getting CVEs done right, like the original mitre team has.

Here is to hoping they can revoke cna status from teams who consistently do not meet a quality bar.

Re: CVE Stuffing

#64

Post by beardedwizard »

tsimionescu wrote: post #50
beardedwizard wrote: post #40

Earlier quoted context omitted.

No disagreement here. What is dangerous for me is the idea that difficulty upgrading for security fixes does not predict the same difficulty for other fixes. It's not that security bugs are uniquely hard to patch, it's that dependency management on the whole is neglected and security gets the blame. Those crusty old dependencies and the processes around them are an operational risk, we should be lowering the bar to j…

You are assuming that this is about dependencies. OP's example is explicitly "gdb crashes when opening on a malformed core dump and can be used for DoS". If you were working on GDB and got this bug report, would you consider it a fire to be put out immediately? Or would it be a low-impact bug to be looked at when someone gets some free time? The OP is complaining that, if there is a CVE associated for whatever stupid…

That's fair

Re: CVE Stuffing

#65

Post by astrobe_ »

currymj wrote: post #46
tptacek wrote: post #44

Earlier quoted context omitted.

My basic take is: if "CVE stuffing" bothers you, really the only available solution is to stop being bothered by it, because the incentives don't exist to prevent it. People submitting bogus or marginal CVEs are going to keep doing that, and CNAs aren't staffed and funded to serve as the world's vulnerability arbiters, and even if they were, people competent to serve in that role have better things to do. The problem…

I suspect for both peer review and CVEs, and probably some similar situations I'm not thinking of, it's not just a misconception, it's often more like wishful thinking. People really want there to be a way of telling what's good and important that doesn't cost them any money or effort. Ironically these systems can sort-of work for that purpose, only if people don't try to use them for that purpose.

I think both are instances of Goodhart-Campbell-Strathern's law: "When a measure becomes a target, it ceases to be a good measure."

Re: CVE Stuffing

#67

Post by tamirzb »

eyeareque wrote: post #63

Mitre is a us gov supported team, and previously they could not scale to the need of their efforts. They did the best they could, but they still had a lot of angry people out there. The whole world uses CVEs but it is US funded by the way. In come new CNAs, scale the efforts through trusted teams, which makes sense. The mitre team can only do so much on their own. Unfortunately I don’t think anyone will be as strict…

The problem though is that issues with CVEs are not caused only by bad CNAs. MITRE (understandably) doesn't have the resources to verify every CVE request it receives, which have resulted in bad CVE details being filed on multiple occasions.

I wonder if maybe, instead of trying to fix CVEs, we could try to think about creating alternatives? I know some companies already use their own identifiers (e.g. Samsung with SVE), so perhaps a big group of respected companies can come together to create a new unified identifier? Just an idea though.

Re: CVE Stuffing

#68

Post by RyJones »

We get dozens of "high-priority" security issues filed that are resolved with "we're an open-source project; this information is public on purpose".

Our bug bounty clearly outlines that chat, Jira, Confluence, our website - all out-of-bounds. Almost all of our reports are on those properties.

Re: CVE Stuffing

#69

Post by dx87 »

tptacek wrote: post #39
dx87 wrote: post #21

I think this goes hand-in-hand with people naming security vulnerabilities and trying to make it a big spectacle. Sometimes it is a legit serious vulnerability, like shellshock or heartbleed, but a lot are just novices trying to get their 15 minutes of fame. I remember a few years back there was a "vulnerability" named GRINCH, where the person who discovered it claimed it was a root priviledge escalation that worked…

It's hard for me to think of a serious downside for named vulnerabilities. People who try to name sev:lo bugs get made fun of; it backfires.

It just causes extra annoyance at work. There have been a few times when some named vulnerability gets covered by a generic tech website, and the next day at work my inbox has 2-3 meeting invites from non-technical project managers to discuss what needs to be done to mitigate the vulnerability, regardless of its severity, and without even knowing if our organization is vulnerable to it.

Re: CVE Stuffing

#70

Post by seanwilson »

ryanlol wrote: post #33
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.

This is not a helpful message in the vast majority of cases. Lots of servers out there that always return 200

> Lots of servers out there that always return 200

That's poor configuration for most public websites that you want indexed by search bots that's worth fixing. It's called a soft 404, and makes it troublesome to detect when links are invalid, break or have moved. Google will even warn you about it: https://developers.google.com/search/docs/advanced/crawling/...

Post reply on HN