5 ms·

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it does to help. It's just a silly historical artifact that we treat DoS as special, imo.

jpollock 7mo ago
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 7mo ago
  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 7mo ago
    You're making too much sense for a computer security specialist.
- michaelt 7mo ago
  > 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 7mo ago
    If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.
    - paulddraper 7mo ago
      Okay, then the “vulnerability” is de facto simply transitioning the system to an acceptable state.
    - lazyasciiart 7mo ago
      Until any bad customer learns about the fail-open.
      - eru 7mo ago
        If bad actors learn about the fail-close, they can conceivably cause you more harm.
        gopher_space 7mo ago
        This is a losing money vs. losing freedom situation.
        eru 7mo ago
        Maybe. But for a company everything is fungible.
    - prmoustache 7mo ago
      If that is the mindset in your company, why even bother looking for vulnerabilities?
      - jpollock 7mo ago
        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.
- vasco 7mo ago
  > 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 7mo ago
    Literal blackmailing, same as ransomware.
- eru 7mo ago
  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 7mo ago
    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.
- TeMPOraL 7mo ago
  > 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.
bawolff 7mo ago
The real problem is that we treat vulnerabilities as binary without nuance. Whether a security vulnerability is an issue depends on context. This comes up a lot for DoS (and especially ReDoS) as it is comparatively rare for it to be real, but it can happen for any vulnerability type.
- staticassertion 7mo ago
  I don't really agree. Maybe I do, but I probably have mixed feelings about that at least. DoS is distinct because it's only considered a "security" issue due to arbitrary conversations that happened decades ago. There's simply not a good justification today for it. If you care about DoS, you care about almost every bug, and this is something for your team to consider for availability. That is distinct from, say, remote code execution, which not only encompasses DoS but is radically more powerful. I think it's entirely reasonable to say "RCE is wroth calling out as a particularly powerful capability". I suppose I would put it this way. An API has various guarantees. Some of those guarantees are on "won't crash", or "terminates eventually", but that's actually insanely uncommon and not standard, therefor DoS is sort of pointless. Some of those guarantees are "won't let unauthorized users log in" or "won't give arbitrary code execution", which are guarantees we kind of just want to take for granted because they're so insanely important to the vast majority of users. I kinda reject the framing that it's impossible to categorize security vulnerabilities broadly without extremely specific threat models, I just think that that's the case for DoS. There are other issues like "is it real" ie: "is this even exploitable?" and there's perhaps some nuance, and there's issues like "this isn't reachable from my code", etc. But I do think DoS doesn't fall into the nuanced position, it's just flatly an outdated concept.
  - bawolff 7mo ago
    I am kind of sympathetic to that view. In practise i do find most DoS vulns to be noise or at least fundamentally different from other security bugs because worst case you get attacked, have some downtime, and fix it. You dont have to worry about persistence or data leaks. But at the same time i don't know. Pre-cloudflare bringing cheap ddos mitigation to the masses, i suspect most website operators would have preferred to be subject to an xss attack over a DoS. At least xss has a viable fix path (of course volumetric dos is a different beast than cve type dos vulns)
Lichtso 7mo ago
> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.
- staticassertion 7mo ago
  I think this is just sort of the wrong framing. Yes, a plane having a DoS is a critical failure. But it's critical at the level where you're considering broader scopes than just the impact of a local bug. I don't think this framing makes any sense for the CVE system. If you're building a plane, who cares about DoS being a CVE? You're way past CVEs. When you're in "DoS is a security/ major boundary" then you're already at the point where CVSS etc are totally irrelevant. CVEs are helpful for describing the local property of a vulnerability. DOS just isn't interesting in that regard because it's only a security property if you have a very specific threat model, and your threat model isn't that localized (because it's your threat model). That's totally different from RCE, which is virtually always a security property regardless of threat model (unless your system is, say, "aws lambda" where that's the whole point). It's just a total reversal.
- technion 7mo ago
  These redos vulnerabilities always come down to "requires a user input of unbounded length to be passed to a vulnerable regex in JavaScript ". If someone is building a hard real time air plane guidance system they are already not doing this. I can produce a web server that prints hello world and if you send it enough traffic it will crash. If can put user input into a regex and the response time might go up by 1ms and noone will say its suddenly a valid cve. Then someone will demonstrate that with a 1mb input string it takes 4ms to respond and claim they've learnt a cve for it. I disagree. If you simply use Web pack youve probably seen a dozen of these where the vulnerable input was inside the Web pack.config.json file. The whole category should go in the bin.
  - bandrami 7mo ago
akerl_ 7mo ago
Maybe we should start issuing CVEs for all bugs that might negatively impact the security of a system.
- ranger207 7mo ago
  The Linux kernel approach
  - deleted 7mo ago
    [deleted]
kortilla 7mo ago
If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.
- staticassertion 7mo ago
  > If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. Well obviously I reject that, right? That's sort of my point. > If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless. That doesn't follow at all. If I say "availability is an operational concern and not a security concern" it does not follow then that "remote code execution is not a security concern" whatsoever.
  - kortilla 7mo ago
    No, the answer to every security concern can be “don’t attach it to a network” in your view. That’s why it’s so incredibly stupid to not have availability in the framework.
SAI_Peregrinus 7mo ago
If DoS is a vulnerability, then bad UX is also a vulnerability because it's functionally a DoS if it's bad enough. If users can't use the software it doesn't matter whether they can't because of an attacker or because of the software's inherent unusability.

jpollock 7mo ago

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 7mo ago
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 7mo ago
  You're making too much sense for a computer security specialist.
michaelt 7mo ago
> 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 7mo ago
  If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.
  - paulddraper 7mo ago
    Okay, then the “vulnerability” is de facto simply transitioning the system to an acceptable state.
  - lazyasciiart 7mo ago
    Until any bad customer learns about the fail-open.
    - eru 7mo ago
      If bad actors learn about the fail-close, they can conceivably cause you more harm.
      - gopher_space 7mo ago
        This is a losing money vs. losing freedom situation.
        eru 7mo ago
        Maybe. But for a company everything is fungible.
  - prmoustache 7mo ago
    If that is the mindset in your company, why even bother looking for vulnerabilities?
    - jpollock 7mo ago
      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.
vasco 7mo ago
> 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 7mo ago
  Literal blackmailing, same as ransomware.
eru 7mo ago
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 7mo ago
  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.
TeMPOraL 7mo ago
> 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.

bawolff 7mo ago

The real problem is that we treat vulnerabilities as binary without nuance. Whether a security vulnerability is an issue depends on context. This comes up a lot for DoS (and especially ReDoS) as it is comparatively rare for it to be real, but it can happen for any vulnerability type.

staticassertion 7mo ago
I don't really agree. Maybe I do, but I probably have mixed feelings about that at least. DoS is distinct because it's only considered a "security" issue due to arbitrary conversations that happened decades ago. There's simply not a good justification today for it. If you care about DoS, you care about almost every bug, and this is something for your team to consider for availability. That is distinct from, say, remote code execution, which not only encompasses DoS but is radically more powerful. I think it's entirely reasonable to say "RCE is wroth calling out as a particularly powerful capability". I suppose I would put it this way. An API has various guarantees. Some of those guarantees are on "won't crash", or "terminates eventually", but that's actually insanely uncommon and not standard, therefor DoS is sort of pointless. Some of those guarantees are "won't let unauthorized users log in" or "won't give arbitrary code execution", which are guarantees we kind of just want to take for granted because they're so insanely important to the vast majority of users. I kinda reject the framing that it's impossible to categorize security vulnerabilities broadly without extremely specific threat models, I just think that that's the case for DoS. There are other issues like "is it real" ie: "is this even exploitable?" and there's perhaps some nuance, and there's issues like "this isn't reachable from my code", etc. But I do think DoS doesn't fall into the nuanced position, it's just flatly an outdated concept.
- bawolff 7mo ago
  I am kind of sympathetic to that view. In practise i do find most DoS vulns to be noise or at least fundamentally different from other security bugs because worst case you get attacked, have some downtime, and fix it. You dont have to worry about persistence or data leaks. But at the same time i don't know. Pre-cloudflare bringing cheap ddos mitigation to the masses, i suspect most website operators would have preferred to be subject to an xss attack over a DoS. At least xss has a viable fix path (of course volumetric dos is a different beast than cve type dos vulns)

Lichtso 7mo ago

> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

staticassertion 7mo ago
I think this is just sort of the wrong framing. Yes, a plane having a DoS is a critical failure. But it's critical at the level where you're considering broader scopes than just the impact of a local bug. I don't think this framing makes any sense for the CVE system. If you're building a plane, who cares about DoS being a CVE? You're way past CVEs. When you're in "DoS is a security/ major boundary" then you're already at the point where CVSS etc are totally irrelevant. CVEs are helpful for describing the local property of a vulnerability. DOS just isn't interesting in that regard because it's only a security property if you have a very specific threat model, and your threat model isn't that localized (because it's your threat model). That's totally different from RCE, which is virtually always a security property regardless of threat model (unless your system is, say, "aws lambda" where that's the whole point). It's just a total reversal.
technion 7mo ago
These redos vulnerabilities always come down to "requires a user input of unbounded length to be passed to a vulnerable regex in JavaScript ". If someone is building a hard real time air plane guidance system they are already not doing this. I can produce a web server that prints hello world and if you send it enough traffic it will crash. If can put user input into a regex and the response time might go up by 1ms and noone will say its suddenly a valid cve. Then someone will demonstrate that with a 1mb input string it takes 4ms to respond and claim they've learnt a cve for it. I disagree. If you simply use Web pack youve probably seen a dozen of these where the vulnerable input was inside the Web pack.config.json file. The whole category should go in the bin.
- bandrami 7mo ago

akerl_ 7mo ago

Maybe we should start issuing CVEs for all bugs that might negatively impact the security of a system.

ranger207 7mo ago
The Linux kernel approach
- deleted 7mo ago
  [deleted]

kortilla 7mo ago

If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless.

staticassertion 7mo ago
> If I can cause a server to not serve requests to anyone else in the world by sending a well crafted set of bytes, that’s absolutely a vulnerability because it can completely disable critical systems. Well obviously I reject that, right? That's sort of my point. > If availability isn’t part of CIA then a literal brick fulfills the requirements of security and the entire practice of secure systems is pointless. That doesn't follow at all. If I say "availability is an operational concern and not a security concern" it does not follow then that "remote code execution is not a security concern" whatsoever.
- kortilla 7mo ago
  No, the answer to every security concern can be “don’t attach it to a network” in your view. That’s why it’s so incredibly stupid to not have availability in the framework.

SAI_Peregrinus 7mo ago

If DoS is a vulnerability, then bad UX is also a vulnerability because it's functionally a DoS if it's bad enough. If users can't use the software it doesn't matter whether they can't because of an attacker or because of the software's inherent unusability.