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

91–100 of 108 posts

Re: CVE Stuffing

#91

Post by _kbh_ »

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

I would email MITRE responding to your own email that they haven't responded to, after a couple months. I had to request a status update nearly two months later to get a response once, I suspect they are busy.

Re: CVE Stuffing

#92

Post by saagarjha »

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.

Related, Apple marks any use of MD5 with a warning if you use their SDKs. Good luck getting rid of it if you’re using Swift, because the community has not yet decided whether silencing warnings is something they would like in the language or not. I’m getting kind of sick of using dlsym to fish out the function pointer :(

Re: CVE Stuffing

#93

Post by saagarjha »

ungamed wrote: post #88
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…

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.

This is exactly the attitude we’re talking about. Ok, if you do a bunch of things maybe it could make the service throw a disk usage warning email your way. But a service that is actually crashing now is obviously quite a bit more important.

Re: CVE Stuffing

#94

Post by saagarjha »

hannob wrote: post #18

The whole problem is that at some point people started seeing CVEs as an achievement, as "if I get a CVE it means I found a REAL VULN". While really CVEs should just be seen as an identifier. It means multiple people talking about the same vuln know they're talking about the same vuln. It means if you read an advisory about CVE-xxx-yyy you can ask the vendor of your software if they already have a patch for that. It…

This is also annoying because if you ask for a CVE you can get placed in the bucket with people who are just looking for a thing they can talk about, when in fact you’d like to make the bug searchable to other people.

Re: CVE Stuffing

#95

Post by TecoAndJix »

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…

This is a large part of my job. If something pops in the news that mentions our tech/industry/posture (or I suspect it will get c-suite attention) I immediately do a write up just like that. Depending on the severity (or even media “buzz”) I will include screenshots of my investigation and CC the relevant architects/managers. Still, that sometimes leads to managers wanting a meeting to discuss the email further but it GREATLY reduces panic emails when something crosses their newsfeed. On this topic - I also run our vulnerability management program and have to stress that CVSS score is not the lone factor on how much we care. I get lots of emails from people in the company saying “hey, did you see this”? for some random no impact vulnerability but am MORE than happy to thank them for the vigilance and explain why it’s not an impact because I want them to care.

Re: CVE Stuffing

#96

Post by geofft »

anonydsfsfs wrote: post #90
geofft wrote: post #87

Earlier quoted context omitted.

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

That's fair, I should have added that as an exception too. Another similar case: you're writing a shell script and you can assume the target machines all have md5sum installed but not necessarily b3sum.

Re: CVE Stuffing

#97

Post by Fnoord »

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…

One bad ([1]) side aspect of this that low signal to noise rate leads to fatigue. At some point it can lead to high priority information (in this case: real bug bounties) being missed. Instead of manually plowing through it you could automate declining obvious bogus information (such as spam) but it might lead to the same. Hence when sometimes real mail gets lost in spam folder.

[1] Arguably bad, depending on your interests. Because such can be intended by an adversary.

Re: CVE Stuffing

#98

Post by jeltz »

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…

How do they contact you? I have never got any report.

Re: CVE Stuffing

#99

Post by MrStonedOne »

jeltz wrote: post #98
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…

How do they contact you? I have never got any report.

emails to addresses like security@domain.name or webmaster@

Re: CVE Stuffing

#100

Post by beardedwizard »

arp242 wrote: post #73
beardedwizard wrote: post #49

Earlier quoted context omitted.

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.

I see your point
Post reply on HN