3 ms·

I think OP is over-egging their point, especially recommending that repos ban reports of ReDoS. This isn't "security noise" to the same degree as "misconfigured

I think OP is over-egging their point, especially recommending that repos ban reports of ReDoS. This isn't "security noise" to the same degree as "misconfigured" certs, for example. For many services there is a genuine concern for DoS, and ReDoS really isn't the same as "traditional DoS", because the latter has a vastly larger footprint and far more likely to be engaging is extra criminal activity to set up and execute, and therefore far easier to attribute and later prosecute. While for a service a ReDoS can be smuggled in easily, from a single source that's easier to mask, and often passed off as "legitimate" traffic / query making it easier to avoid prosecution. So I think it's going too far to recommend just ignoring all ReDoS. Certainly projects on a project by project basis should say how much they care about ReDoS and grade the severity based on their own evaluation. For some projects that'll be almost nothing, for others it may be more serious.

dwheeler 4y ago
I agree. The complication is that it's not just "per project" but "can an attacker exploit it in a way that matters?". If so-called ReDoS can only be triggered by trusted data, it's not a vulnerability.
- xnorswap 4y ago
  If something relies on trusted data I'd argue there isn't a ReDoS vulnerability there at all. In some ways this reminds of XML/JSON parsing vulnerabilities. If ran on untrusted / unsanitised data they can be absolutely tier 1 critical (remote code execution) but if parsing trusted data then they are essentially benign. If someone claims you have a vulnerability and you disagree then it's on the submitter to prove it with a PoC or a plausible mechanism for triggering it. That doesn't however invalidate the whole class of vulnerabilities.
smolder 4y ago
> ReDoS really isn't the same as "traditional DoS", because the latter has a vastly larger footprint You're confusing DoS (denial of service, a very broad class of problems that includes ReDoS) with DDoS, which is a distributed denial of service attack, something that disables a service using multiple malicious sources of input. The terms are used interchangeably (often erroneously) a lot, but the single-D DoS needn't have a "big footprint". It could be making their server crash with a single byte somewhere, like a particular old Linksys router exploit some may remember.

dwheeler 4y ago

I agree. The complication is that it's not just "per project" but "can an attacker exploit it in a way that matters?". If so-called ReDoS can only be triggered by trusted data, it's not a vulnerability.

xnorswap 4y ago
If something relies on trusted data I'd argue there isn't a ReDoS vulnerability there at all. In some ways this reminds of XML/JSON parsing vulnerabilities. If ran on untrusted / unsanitised data they can be absolutely tier 1 critical (remote code execution) but if parsing trusted data then they are essentially benign. If someone claims you have a vulnerability and you disagree then it's on the submitter to prove it with a PoC or a plausible mechanism for triggering it. That doesn't however invalidate the whole class of vulnerabilities.

smolder 4y ago

> ReDoS really isn't the same as "traditional DoS", because the latter has a vastly larger footprint You're confusing DoS (denial of service, a very broad class of problems that includes ReDoS) with DDoS, which is a distributed denial of service attack, something that disables a service using multiple malicious sources of input. The terms are used interchangeably (often erroneously) a lot, but the single-D DoS needn't have a "big footprint". It could be making their server crash with a single byte somewhere, like a particular old Linksys router exploit some may remember.