search

vin01 / bogus-cves

Got a bogus CVE someone got for a non-vuln? Please share here!
23 stars 1 forks source link

Is CVE-2020-26159 really bogus? #2

Closed Marcono1234 closed 1 year ago

Marcono1234 commented 1 year ago

At least compared to the other examples there was proper communication with the maintainer here. Starting at https://github.com/kkos/oniguruma/issues/207#issuecomment-701051852:

Reporter: does [...] represent a security issue or just a bug?

Maintainer: I don't know what to answer, but I wasn't doing anything wrong, just exceeding the buffer size, so it's probably a security issue.

Reporter: I've asked MITRE to assign a CVE number for this issue; I've tried to summarize it as best I could, I'll write back if they assign one. Thanks!

Of course it would have been better if this was investigated more in detail, and maybe if the reporter had first asked the maintainer if a CVE should be requested (and who would do that). But I am not sure if that belongs to the same category as the other bogus CVEs.

vin01 commented 1 year ago

I added this based on https://nvd.nist.gov/vuln/detail/CVE-2020-26159 (It got rejected) and of course details from the linked issue. A lot of times where an overflow or overwrite is involved, it is not exploitable unless an attacker can control the data and have enough room to inject code/commands/malicious-data. In this case the change was from > to >= (1 byte), which is most likely what got it rejected since it is not good enough to be abused and also depends on the context and privilege with which the tool is being used.

But I think you have a point here that often enough, these issues are not easy to triage exactly because of this kind of quirks and require familiarity with exploit development or the tool's codebase/features/usage-scenarios. For that reason just a bug also gets treated as CVE because they are just unsure.