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

Be thankful you only receive automated security reports about an open .git directory. There is some guy/company who goes around running a web spider connected to some shitty antivirus which automatically submits false abuse reports to site ISPs claiming that their customers are hosting viruses. This happened to me twice; I think after the second time my ISP started rejecting these reports outright since I haven’t seen any new ones for a few years now, even though they’re clearly still at it (or, maybe, finally stopped last year after getting DDoSed?)[0].

Automated security scanning by people who don’t know what they are doing has become an enormous hassle in so many ways and really is damaging the ability to find and handle true threats.

[0] https://twitter.com/badlogicgames/status/1267850389942042625

Speaking of "security exploits" consisting of reading publicly available information: Tarsnap has public mailing lists with public mailing list archives, and at least once a month I get an email warning me that my "internal emails" are accessible.

> 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

> I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs.

Yes, being the discoverer of a CVE is a major resume item. Pen testers who have a CVE to their name can charge more. Companies can charge more for sending them.

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.

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

> Apparently because my site didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me.

There's no good reason that folder should exist except for a joke, so how is this not a helpful message in the vast majority of cases? All lint rules have exceptions, doesn't make them not useful.

Hi there. Danny here, co founder at Snyk and the guy behind the zip slip research. First, at no point we claimed that this is a new type of vulnerability, the contrary, in every talk i gave, most are on youtube, i started with saying that it's a 30yo vuln, originally published in phrack showing the actual phrack issue. Secondly, the real problem here is that 30 years later, in some languages like Java, more than 90% of archive extraction implementations are vulnerable to this issue, like really vulnerable, RCE kind of vulnerable. so no, this is not just a "zip format gotcha", this is a real issue in real apps. this is the kind of vulnerability that every security person knows of, but not that many developers do. when they write extraction code, they most often do it without considering the path traversal issues. Some languages solved it by providing a simple api for you to extract an archive, like python's zipfile.extractall(), this is great! but others like java stayed behind and made the developers either write it themselves (wrongly) or copy and paste it from stackoverflow (most answers are vulnerable).. fast forward 30 years, still too many vulnerable apps (we identified several hundreds) that are vulnerable. since this is an issue of awareness, we thought it would be good to have a better name, just like "zip bomb" is well know, zip slip should be too. neither are zip only issues (others archivers and compressors are affected), but both make it simple to remember. anyways.. looking back it's very easy to see the impact of such research, i'm not talking about snyk's marketing and such, i'm taking about hundreds of open source projects fixing the issue (maintainers confirming it), CVEs assigned, many developes learning about it (blog post, talks, etc). peace

I believe the ZipSlip was/is a marketing effort for snyk.

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.

The whole situation around CVE in Tensorflow is very painful, you get GitHub security notifications for any public repository using TF because of a "known CVE", even though it's basically just a train.py script that is not deployed anywhere.

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.

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.

I checked, it seems to be a student of Seoul National University, South Korea. https://github.com/donghyunlee00/CVE

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

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.

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 SVE), so perhaps a big group of respected companies can come together to create a new unified identifier? Just an idea though.

This is a staple of audit report stuffing. Somebody got an idea that disclosing a version of anything anywhere is a huge security hole, so now any publicly visible version string generates a "moderate" (they are usually not as brazen as to call it "critical") security report.

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

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

> The current state of CVEs and CVE scanning is that you'll have to wrangle with bullshit security reports if you run any nontrivial software.

Especially if you have customers who outsourced their infosec to the lowest bidder who insist every BS CVE is critical and must be fixed.

The non stop stream of emails every day certainly sucks but falls far short of my employers false positive process which requires several emails explaining why it’s false positive and following up to make sure the waiver is applied so as to not impact our security rating instead of just reassigning the jira ticket and adding false positive label.

We use Nessus and it's not too bad on the false positive front. I usually check the scan results every week or two to see if it finds anything new, and I know our Head of IT also keeps an eye on them. In an ideal world we'd automate this away but have a raft of more pressing priorities.

We also use tools like Dependabot to keep an eye out for vulnerabilities in our dependencies, and update them to patched versions. This is genuinely useful and a worthwhile timesaver on more complex projects.

It's easy to be cynical about automated scanning (and pen-testing for that matter) and, although it's often needed as a checkbox for certification, it can certainly add value to your development process.

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.

Our security team at a previous employer previously added a systemwide checker to our github enterprise installation that would spam comments on any change to a file in which Math.random is used. The idea is that anyone using random numbers must be implementing a cryptographic protocol and therefore should not be using Math.random as it's not a CSPRNG.

So all the AB tests, percentage rollouts etc. started getting spam PR comments until they were made to turn it back off again.

Frankly if a teammate was writing their own crypto algorithm implemntation in the bog standard web app we working on, that would be more concerning than which RNG they're using.

I've seen exactly this many times in audits (gets them a high score!). If they flag it and not check the usage I know they didn't bother putting anyone good on the audit or only ran automated stuff and it is pretty much useless. The same can now be said for sha1, gets them results quickly and looks good on the final report.

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 :(

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!”

TBH, if you are doing security with it, it's obviously wrong, but if you are not, it also is because way better (faster) options exist for non security usage...