[mmastrac]

I got hit with a CVE spammer last year which forced me to re-release a library to fix a fake vulnerability that cannot be disputed in any way -- https://gist.github.com/6en6ar. They do nothing but post exploits where long strings purportedly take a long time to process -- because they are slow to construct! And even more fun, the example exploits often don't even compile.

I assumed it was a human, but I'm starting to wonder if this was an early CVE-farming AI bot.

The CVE process is very broken and extremely exploitable as a DoS against humans.

[minitech]

> exploits where long strings purportedly take a long time to process -- because they are slow to construct!

That’s not an accurate characterization of ReDoS. Even if a long string is required to produce the behavior, the vulnerability is that the string takes a disproportionately long time to process even for its length, such that it becomes disproportionately easy to bring down a service. The CVE scoring system gives denial of service way too much weight if you ask me, but it’s not a fake vulnerability.

[bawolff]

However i think there are people spamming fake redos vulns just to get creds. Things like, yeah, if you passed in 10 mb of input this would be a problem, but also some other layer limits it to 100 bytes.

ReDos is real in certain circumstances, but it is way way overhyped and usually bullshit.

[mmastrac]

You missed the point.

The code purported to be vulnerable is not slow because of the length of the string. The "example exploit" is slow because the reports use slow methods to construct the string under test. When timing the affected methods, they are _not_ slow.

[minitech]

Well, you didn’t link to that example exploit, and a random sampling from their profile looked legitimate. Do you have the specific link?

[hoten]

Can you explain how a CVE "awaiting analysis" forced you to "resolve" it? Just wondering how this works.

I looked at the first one (https://nvd.nist.gov/vuln/detail/CVE-2024-25355) and obviously they time way too much of the "vulnerability", attributing their own test setup to your library (as you mentioned).

So- someone reports a CVE (can just anyone do that?), and without any validation, some other services dings your library and now random users ask you "can you please fix your library"?

[mmastrac]

That wasn't the library I had an issue with but the general problem is this:

Downstream consumers of a library that have integrated Dependabot get alerts for CVEs filed against a library, even if the are "awaiting analysis". Those consumers send messages asking for a resolution, and there's no trivial way to push back that an advisory is false.

For example, here's the one I'm griping about. This is marked as _Github reviewed_:

https://github.com/advisories/GHSA-fqhp-rhm6-8rrj

I used the reporter's reproduction and could not reproduce the slowdown at all. It turns out that the testcase was slow only because they were printing the URL under test.

https://github.com/progscrape/urlnorm/issues/1

As a maintainer, I have a choice: either I need to go and clean up all of the automated tools that respond to CVE spam, OR I just release a new version of a library, fuck it all and move on with my life after blocking the reporter.

For what it's worth, Github did not respond to reports about this user, so I got to the point where I think everything is broken and I no longer care about anything other than clearing those alerts out.

[costyspam]

Could we introduce a real monetary cost to posting a bug? That'd disincentivize making massive amounts of noise, but allows people to compete for rewards with worthwhile answers.

[hoten]

I would rather some sort of authenticated peer-rating system. If someone has a history of making good, useful bug reports- then convey that in some way to project maintainers reading bug reports.

GitHub is in a good position to do this at scale.

[costyspam]

I'm afraid any peer-rating system would be suspectible to same kind of point-manipulation other platforms are prone to, slightly increasing the latency but not the amount of spam. Returnable tokens worth real money would make this category of attacks completely infeasible

[secondcoming]

Bad regex took down cloudflare due to backtracking.