[jpollock]

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure.

If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly.

Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

Then, "what happens when people find out I pay out on shakedowns?"

[staticassertion]

If the system "fails open" then it's not a DoS, it's a privilege escalation. What you're describing here is just a matter of threat modeling, which is up to you to perform and not a matter for CVEs. CVEs are local properties, and DoS does not deserve to be a local property that we issue CVEs for.

[otabdeveloper4]

You're making too much sense for a computer security specialist.

[michaelt]

> If the system is configured to "fail open", and it's something validating access (say anti-fraud),

The problem here isn't the DoS, it's the fail open design.

[jpollock]

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

[prmoustache]

If that is the mindset in your company, why even bother looking for vulnerabilities?

[jpollock]

There is _always_ fraud, and you can't stop it all. All you can do is try to minimize the cost of the fraud.

There is an "acceptable" fraud rate from a payment processor. This explains why there are different rates for "card present" and "card not present" transactions, and why things like Apple Pay and Google Pay are popular with merchants.

[everforward]

You are really running with scissors there. If anyone with less scrupulous morals notices, you’re an outage away from being in deep, deep shit.

The best case is having your credit card processing fees like quadruple, and the worst case is being in a regulated industry and having to explain to regulators why you knowingly allowed a ton of transactions with 0 due diligence.

[TeMPOraL]

The concept of due diligence recognizes the limits, past which it becomes too much, or undue.

[lazyasciiart]

Until any bad customer learns about the fail-open.

[eru]

If bad actors learn about the fail-close, they can conceivably cause you more harm.

[gopher_space]

This is a losing money vs. losing freedom situation.

[eru]

Maybe. But for a company everything is fungible.

[paulddraper]

Okay, then the “vulnerability” is de facto simply transitioning the system to an acceptable state.

[TeMPOraL]

> Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

But that is what security is in the real world anyway. Once you move past the imaginary realms of crypto and secure coding that some engineers daydream in, the ultimate reality is always about "do I want to spend $X dealing with consequences of ${specific kind of atack}, or $Y on trying to prevent it" - and the answer is to consider how much $X is likely to be, and how much it'll be reduced by spending $Y, and only spending while the $Y < reduction in $X.

[vasco]

> Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

> Then, "what happens when people find out I pay out on shakedowns?"

What do you mean? You pay to someone else than who did the DoS. You pay your way out of a DoS by throwing more resources at the problem, both in raw capacity and in network blocking capabilities. So how is that incentivising the attacker? Or did you mean some literal blackmailing??

[jpollock]

Literal blackmailing, same as ransomware.

[eru]

Also in eg C code, many exploits start out would only be a DoS, but can later be turned into a more dangerous attack.

[staticassertion]

If you're submitting a CVE for a primitive that seems likely to be useful for further exploitation, mark it as such. That's not the case for ReDOS or the vast majority of DoS, it's already largely the case that you'd mark something as "privesc" or "rce" if you believe it provides that capability without necessarily having a full, reliable exploit.

CVEs are at the discretion of the reporter.