CVE Stuffing
jerrygamblin.com
CVE Stuffing
1–10 of 108 posts
Re: CVE Stuffing
#2Didn't check who filled those bugs, but I've seen companies requiring having discovered CVE to apply for some jobs, and the natural consequence is gaming the system...
Re: CVE Stuffing
#3Didn't check who filled those bugs, but I've seen companies requiring having discovered CVE to apply for some jobs, and the natural consequence is gaming the system...
I checked, it seems to be a student of Seoul National University, South Korea. https://github.com/donghyunlee00/CVE
Re: CVE Stuffing
#4See additional context in this issue in docker-library/memcached: https://github.com/docker-library/memcached/issues/63#issuec...
And this issue in my docker-adminer: https://github.com/TimWolla/docker-adminer/issues/89
Re: CVE Stuffing
#5Way 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 didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me.
Got like 4 or 5 before i decided to make it 404 so they would stop, mainly because i didn't want to bring false positive fatigue on to "security exploit" subject line emails.
I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs. Might as well just rip that bandaid off now and stop trusting anything besides the debian security mailing list.
Re: CVE Stuffing
#6I'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 out a fix because our customers may already be aware that our product is shipping with a known CVE.
There are occasions in which I recognize a CVE as a vulnerability to a legitimate possible threat to an asset. By and large, however, they seem to be marketing material for either organizations offering "protection" or academics seeking publication.
I think like anything else of value, inflation will eat away at the CVE system until something newer and once again effective will come along.
Re: CVE Stuffing
#7Way 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…
Is there a way to return a custom 404 error handler for .git and a different one for a regular 404 in Apache? Never tried that before.
Re: CVE Stuffing
#8Didn't check who filled those bugs, but I've seen companies requiring having discovered CVE to apply for some jobs, and the natural consequence is gaming the system...
I checked, it seems to be a student of Seoul National University, South Korea. https://github.com/donghyunlee00/CVE
Huh. I wonder if it's a student doing an assignment and not realizing they're submitting to a real database.
Their other GitHub work is following tutorials, labs and courses.
Re: CVE Stuffing
#9Way 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…
> I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs. Might as well just rip that bandaid off now and stop trusting anything besides the debian security mailing list.
Red Hat (my employer), Canonical, and SUSE are also CNAs. I can only speak to ours, but I think our prodsec team does a great job with the resources they've been given. Nobody is perfect, but if you take the time to explain the problem (invalid CVE, wrong severity, bad product assignment, ...) they consistently take the time to understand the issue and will work with whatever other CNA or reporter to fix it. Generally we have a public tracker for unembargoed CVEs, so if it affects us and isn't legitimate or scoped correctly, you might get somewhere by posting there (or the equivalent on Ubuntu/SUSE's tracker).
Perhaps it is just the nature of the open source community Linux distros are a part of, though, that lets them apply it to CVEs as well.
Doesn't help with personal reports though. :-)
Curious, did you get CVE assignments against your personal site? 0.o
Re: CVE Stuffing
#10Way 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…
Is there a way to return a custom 404 error handler for .git and a different one for a regular 404 in Apache? Never tried that before.
Check the ErrorDocument directive for .htaccess files.