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

71–80 of 108 posts

Re: CVE Stuffing

#71

Post by wiredfool »

bostik wrote: post #62
Shank wrote: post #43

Earlier quoted context omitted.

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 con…

Oh god. One client I work for does automated scans, and we had an s3 bucket set up as a static site.

They freaked out when /admin/ returned permission errors, essentially a 404, because it was information leakage about admin functions of the website.

Re: CVE Stuffing

#72

Post by akerl_ »

dx87 wrote: post #69
tptacek wrote: post #39

Earlier quoted context omitted.

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.

It seems like there may be value in writing up a template for vulnerability comms:

“Hi folks, a new vulnerability has been disclosed (CVE-####-####). We’ve assessed this vulnerability, and it doesn’t affect our infrastructure because [we don’t use the affected software|we don’t use the vulnerable configuration|the vulnerability is mitigated by other security controls].”

If the worst impact of naming vulnerabilities is that security-related technical staff have to politely decline a couple meeting invites, I’m going to consider the practice an overall win.

Re: CVE Stuffing

#73

Post by arp242 »

beardedwizard wrote: post #49
arp242 wrote: post #47

Earlier quoted context omitted.

Who is talking about "crusty old dependencies"? Or processes which are an "operational risk"? The previous poster never mentioned any of those things.

They get old and crusty when you have to choose not to patch, or de prioritize those not so serious bugs because the operational cost is too high. Developers shouldn't have to make this call, the cost should be zero.

I think you're making all sorts of assumptions and extrapolations here that I'm not really seeing any hints of. What I see is that someone is responsible for dealing with CVEs, judges its severity as they come in, and concludes that a lot of them are just cruft and not really worthy of a CVE as such. Nothing more, nothing less.

Re: CVE Stuffing

#74

Post by eyeareque »

tamirzb wrote: post #67
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 SV…

Getting everyone onboard would be tough, some have tried and failed like osvdb. It requires funding and passionate folks to run it. I think what we could do is spin the cve arm of mitre off into a non profit, and asked all major companies who want to be on the board to chip in and support it. This could have challenges too that would need to be addressed.

Re: CVE Stuffing

#75

Post by arp242 »

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…

> > 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.

Yeah sure, it should be a lint rule, we can quickly agree on that. But that wasn't really my point: my point was that random people from the internet are running these kind of high false-positive linters without asking and start emailing people about it.

Re: CVE Stuffing

#76

Post by koolba »

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.

There’s the “executive” level of this stupidity where an app replaces their md5 OpenSSL calls with their own internal copy pasta of the function.

“Look ma! We’re FIPS compliant now!”

Re: CVE Stuffing

#77

Post by haukem »

How to mark a CVE as invalid or request an update? I tried the Update Published CVE process, but nothing happened not even a reject, just no answer. Multiple CVEs where reported to OpenWrt which are invalid, but we (OpenWrt team) haven't found out how to inform Mitre.

For example CVE-2018-11116: Someone configures an ACL to allow everything and then code executing is possible like expected: https://forum.openwrt.org/t/rpcd-vulnerability-reported-on-v...

and CVE-2019-15513: The bug was fixed in OpenWrt 15.05.1 in 2015: https://lists.openwrt.org/pipermail/openwrt-devel/2019-Novem...

For both CVEs we were not informed, the first one someone asked in the OpenWrt forum about the details of this CVE and we were not even aware that there is one. The second one I saw in a public presentation from a security company mentioning 4 CVEs on OpenWrt and I was only aware of 3.

When we or a real security researcher request a CVE for a real problem as an organization it often takes weeks till we get it, we released some security updates without a CVE, because we didn't want to wait so long. It would also be nice to update them later to contain a link to our detailed security report.

Re: CVE Stuffing

#78

Post by tptacek »

akerl_ wrote: post #72
dx87 wrote: post #69

Earlier quoted context omitted.

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.

It seems like there may be value in writing up a template for vulnerability comms: “Hi folks, a new vulnerability has been disclosed (CVE-####-####). We’ve assessed this vulnerability, and it doesn’t affect our infrastructure because [we don’t use the affected software|we don’t use the vulnerable configuration|the vulnerability is mitigated by other security controls].” If the worst impact of naming vulnerabilities i…

It is, but also worth keeping in mind that vulnerability triage is just an annoying, resource-intensive process. Putting aside the "named vulnerability" thing, the most common prompt for a triage process is "new vulnerability discovered in a dependency"; that will happen several times a week in most significant products. Almost all of those vulnerabilities are marginal, and even the ones that aren't are usually not exposed in a typical use of the dependency. It's just an annoying problem.

Re: CVE Stuffing

#79

Post by DiabloD3 »

So... the real question is, why are CVEs that are just packages of software being accepted to the CVE database anyways? If its in a Docker image, it should be immediately rejected: report the CVE for the precise upstream project instead.

Re: CVE Stuffing

#80

Post by glandium »

wiredfool wrote: post #71
bostik wrote: post #62

Earlier quoted context omitted.

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 con…

Oh god. One client I work for does automated scans, and we had an s3 bucket set up as a static site. They freaked out when /admin/ returned permission errors, essentially a 404, because it was information leakage about admin functions of the website.

That happens when you disable directory enumeration (or whatever name that has) on S3. In that case, it sends 403s (permission denied) instead of 404s.
Post reply on HN