CVE Stuffing • Hacker News Board

Re: CVE Stuffing

#41

Post by beardedwizard » Sat, Jan 02, 2021, 6:17 PM UTC

nullc wrote: post #20

beardedwizard wrote: post #14

Earlier quoted context omitted.

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's sad, however, when a highly non-exploitable crash is treated as a five alarm fire while a "silently corrupts users data" falls to the wayside because people don't generally write security vulnerability reports for those. I've heard from some people that they have considered filing security CVEs against non-security but high user impact bugs in software that they're working on, just to regain control of prioritie…

Agree, but having to make these judgement calls at all is a mistake. We need to get to 'just fix it'.

Re: CVE Stuffing

#42

Post by currymj » Sat, Jan 02, 2021, 6:25 PM UTC

tptacek wrote: post #37

I understand the frustration, and I'm pretty sure the root cause is straightforward ("number of CVEs generated" is a figure of merit in several places in the security field, especially resumes, even though it is a stupid metric). But the problem, I think, contains its own solution. The purpose of CVEs is to ensure that we're talking about the same vulnerability when we discuss a vulnerability; to canonicalize well-kn…

this sounds similar to problems with peer review in academia. it mostly works fine as a guardrail to enforce scholarly norms.

however many institutions want to outsource responsibility for their own high-stakes decisions to the peer review system. whether it's citing peer-reviewed articles to justify policy, or counting publications to make big hiring decisions.

It introduces very strong incentives to game the system -- now getting any paper published in a decent venue is very high-stakes, and peer review just isn't meant for that -- it can't really be made robust enough.

i don't know what the solution is in situations like this, other than what you propose -- get the outside entities to take responsibility for making their own judgments. but that's more expensive and risky for them, so why would they do it?

It feels kind of like a public good problem but I don't know what kind exactly. The problem isn't that people are overusing a public good, but that just by using it at all they introduce distorting incentives which ruins it.

Re: CVE Stuffing

#43

Post by Shank » Sat, Jan 02, 2021, 6:29 PM UTC

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 ways. Long cookie expiration? Report. Any cookie doesn't have `Secure`, including something like `accepted_cookie_permissions`? Report. Public access to an Amazon S3 bucket used to serve downloads for an app? Report. WordPress installed? You'll get about 5 reports for things like having the "pingback" feature enabled, having an API on the Internet, and more.

The issue is that CVEs and prior-art bug bounty payments seem "authoritative" and once they exist, they're used as reference material for submitting reports like this. It teaches new security researchers that the wrong things are vulnerabilities, which is just raising a generation of researchers that look for the entirely wrong things.

[0]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

Re: CVE Stuffing

#44

Post by tptacek » Sat, Jan 02, 2021, 6:34 PM UTC

currymj wrote: post #42

tptacek wrote: post #37

I understand the frustration, and I'm pretty sure the root cause is straightforward ("number of CVEs generated" is a figure of merit in several places in the security field, especially resumes, even though it is a stupid metric). But the problem, I think, contains its own solution. The purpose of CVEs is to ensure that we're talking about the same vulnerability when we discuss a vulnerability; to canonicalize well-kn…

this sounds similar to problems with peer review in academia. it mostly works fine as a guardrail to enforce scholarly norms. however many institutions want to outsource responsibility for their own high-stakes decisions to the peer review system. whether it's citing peer-reviewed articles to justify policy, or counting publications to make big hiring decisions. It introduces very strong incentives to game the system…

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 is the misconception ordinary users have about what CVEs are; the abuses are just a symptom.

Re: CVE Stuffing

#45

Post by VectorLock » Sat, Jan 02, 2021, 6:43 PM UTC

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…

You're absolutely right I get a barrage of these. I've got to think someone out there is selling software to scan for these and spam them around.

Re: CVE Stuffing

#46

Post by currymj » Sat, Jan 02, 2021, 6:46 PM UTC

tptacek wrote: post #44

currymj wrote: post #42

Earlier quoted context omitted.

this sounds similar to problems with peer review in academia. it mostly works fine as a guardrail to enforce scholarly norms. however many institutions want to outsource responsibility for their own high-stakes decisions to the peer review system. whether it's citing peer-reviewed articles to justify policy, or counting publications to make big hiring decisions. It introduces very strong incentives to game the system…

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.

Re: CVE Stuffing

#47

Post by arp242 » Sat, Jan 02, 2021, 6:47 PM UTC

beardedwizard wrote: post #40

arp242 wrote: post #35

Earlier quoted context omitted.

"Never fix it" is one extreme. "Drop all revenue work and rush out a fix" is another. The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.

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…

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

Re: CVE Stuffing

#48

Post by STRML » Sat, Jan 02, 2021, 6:54 PM UTC

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…

Can confirm this; we've gotten more than 20 reports and demands for bounties for "public access" on our open data subdomain (backed by S3), which literally is `public.`.

Then they beg to have the report closed as "informative". We don't comply unless it really is an honest mistake; I don't like the idea of low-quality reporters evading consequences again and again, sending scattershot bug reports in a desperate attempt to catch a team not paying attention.

Re: CVE Stuffing

#49

Post by beardedwizard » Sat, Jan 02, 2021, 7:11 PM UTC

arp242 wrote: post #47

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…

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.

Re: CVE Stuffing

#50

Post by tsimionescu » Sat, Jan 02, 2021, 7:28 PM UTC

beardedwizard wrote: post #40

arp242 wrote: post #35

Earlier quoted context omitted.

"Never fix it" is one extreme. "Drop all revenue work and rush out a fix" is another. The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.

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 reason, the bug suddenly jumps from a "might fix" to "hot potato".