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

81–90 of 108 posts

Re: CVE Stuffing

#81

Post by akerl_ »

tptacek wrote: post #78
akerl_ wrote: post #72

Earlier quoted context omitted.

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

No disagreement on it being a chore. The template doesn’t cut down on the actual work of triaging these, it just (hopefully, in a healthy org) helps avoid the “3 meetings per CVE with non-technical managers” part, which does seem avoidable.

Re: CVE Stuffing

#82

Post by TheDong »

seanwilson wrote: post #56
Kalium wrote: post #53

Earlier quoted context omitted.

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

The reason you're getting downvoted, so you know, is that your original response heavily indicated you _were_ talking about the email reports.

You replied to someone complaining about getting emails and defended it with "but that directory shouldn't exist", implying you disagreed with their take.

You're arguing about something here that no one else is trying to talk about. The poster you originally replied to was only talking about the email case, so your response is contextualized in that case already.

If you original post had been "Yeah, I agree. That would make sense as a CI rule that you run, not as a scanner someone else runs" then you wouldn't have gotten any pushback, but your post was strongly implying a position you apparently don't hold.

Re: CVE Stuffing

#83

Post by TheDong »

beardedwizard wrote: post #41
nullc wrote: post #20

Earlier quoted context omitted.

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

I don't quite get what you mean.

There's finite time and developer effort. You always have to make judgement calls about what to prioritize over what, you can't "just fix it" for literally everything unless you're in a very fortunate position of working in a codebase with minimal tech debt, a mature scope, and sufficient developer-hours.

If you're saying that the CVEs that amount to "update dependency X" or whatever should be "just automatically fixed" rather than have to be prioritized, I agree that should be true for a subset of em... But not every dependency update or CVE resolution is trivial, and even the supposedly trivial ones may still require a certain amount of testing or refactoring.

Re: CVE Stuffing

#84

Post by Macha »

DiabloD3 wrote: post #79

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.

What if the project is the docker image? What if the docker image is the primary distribution method of the software?

Re: CVE Stuffing

#85

Post by jlgaddis »

DiabloD3 wrote: post #79

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.

> ... why are CVEs that are just packages of software being accepted to the CVE database anyways?

Ultimately, because there are now a few hundred [0] CNAs [1] which are "authorized to assign CVE IDs" and, AFAICT, there is nothing in the "CNA rules" [2] that requires them to (attempt to) verify the (alleged) vulnerabilities -- although, in at least some instances, I assume it simply wouldn't be possible for them to do so.

--

> 7.1 What Is a Vulnerability?

> The CVE Program does not adhere to a strict definition of a vulnerability. For the most part, CNAs are left to their own discretion to determine whether something is a vulnerability. [3]

Officially, a "vulnerability" is:

> A flaw in a software, firmware, hardware, or service component resulting from a weakness that can be exploited, causing a negative impact to the confidentiality, integrity, or availability of an impacted component or components.

Fortunately, there is a "Process to Correct Assignment Issues or Update CVE Entries" [5]. In instances of multiple, "duplicate" or "invalid" CVEs, I can see how this might be both frustrating and time-consuming for software developers, though.

--

[0]: https://cve.mitre.org/cve/request_id.html

[1]: https://cve.mitre.org/cve/cna.html

[2]: https://cve.mitre.org/cve/cna/rules.html

[3]: https://cve.mitre.org/cve/cna/rules.html#section_7-1_what_is...

[4]: https://cve.mitre.org/about/terminology.html#vulnerability

[5]: https://cve.mitre.org/cve/cna/rules.html#appendix_c_process_...

Re: CVE Stuffing

#86

Post by jlgaddis »

haukem wrote: post #77

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

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

From your point of view, I'm sure that's probably quite frustrating. From my point of view (as a user), that's completely absurd, should never happen, and is a huge deficiency in the CVE program.

Fortunately, it's possible for the OpenWRT project to become a CNA [0] and gain the ability to assign CVE IDs themselves.

See "Types" under "Key to CNA Roles, Types, and Countries" [1]:

> Vendors and Projects - assigns CVE IDs for vulnerabilities found in their own products and projects.

--

[0]: https://cve.mitre.org/cve/cna.html#become_a_cna

[1]: https://cve.mitre.org/cve/request_id.html#key_cna_roles_and_...

Re: CVE Stuffing

#87

Post by geofft »

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.

In fairness, those sorts of features tend to be subject to scope creep where they start being used for security.

For instance, Linus Torvalds (a very smart person) resisted using something stronger than SHA-1 for Git because he said the purpose of hashes isn't security, it's content-addressable lookup of objects. Which may have been true at the time, but then Git added commit signing. Now if you sign a commit, no matter how strong of an algorithm you use, the commit object references a tree of files via SHA-1. Git is currently undergoing an extremely annoying migration to support new hash algorithms, which could have been avoided.

Also, BLAKE3 is faster than MD5 and also far more secure, so if you're saying "It's okay I'm using MD5 because I want a faster hash and SHA-256 is too slow," there are options other than SHA-256.

If the thing you're trying to hash really really isn't cryptographic at all, you can do a lot better than MD5 in terms of performance by using something like xxHash or MurmurHash.

So, even if it isn't a security vulnerability, using MD5 in a new design today (i.e., where there's no requirement for compatibility with an old system that specified MD5) is a design flaw.

Re: CVE Stuffing

#88

Post by ungamed »

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…

Non exploitable crash can be a denial of service, given the right configuration. Ie, filling up disk core file storage, crashing at the right time can force expensive operations to retry/rollback.

Re: CVE Stuffing

#89

Post by frays »

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…

Thank you for sharing. Very useful.

Re: CVE Stuffing

#90

Post by anonydsfsfs »

geofft wrote: post #87
raverbashing wrote: post #19

Earlier quoted context omitted.

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.

In fairness, those sorts of features tend to be subject to scope creep where they start being used for security. For instance, Linus Torvalds (a very smart person) resisted using something stronger than SHA-1 for Git because he said the purpose of hashes isn't security, it's content-addressable lookup of objects. Which may have been true at the time, but then Git added commit signing. Now if you sign a commit, no mat…

> Also, BLAKE3 is faster than MD5 and also far more secure, so if you're saying "It's okay I'm using MD5 because I want a faster hash and SHA-256 is too slow," there are options other than SHA-256.

True, but BLAKE3 isn't shipped as part of the standard library of many (any?) languages, whereas MD5 is. There are third-party implementations for a lot of languages, but using one of these brings up a lot of problems:

1. Are you sure the implementation doesn't have any bugs? AFAIK, the BLAKE3 team has only created C and Rust implementations, so anything else likely hasn't received the same level of care.

2. How are you going to notified of bugs or vulnerabilities in the implementation? For your language's standard library, it's usually easy to get notified of any bugs or vulnerabilities, but you're probably not going to get that from some random implementation on Github.

3. Pulling in the dependency can be an attack vector in itself. For example, if you use the Javascript implementation on NPM, you're now going to have worry about the NPM author having their account compromised and the package replaced with malicious code.

Post reply on HN