5 ms·

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was awa

by nfm 8mo ago

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

adverbly 8mo ago
Seriously! We also suffer from this. Although in some cases it's due to a Dev dependency. It's crazy how much noise it adds specifically from ReDoS...
- robszumski 8mo ago
  Totally hear you on the noise…but we should want to auto-merge vs ignore, no? Given the right tooling of course.
  - dotancohen 8mo ago
    No
  - UqWBcuFx6NV4r 8mo ago
    We could just skip some steps and I could send you a zip file of malware for you to install on your infra directly if you’d like.
  - deleted 8mo ago
    [deleted]
- monkpit 8mo ago
  ReDoS cves in your dev dependencies like playwright that could literally never be exploited, so annoying.
staticassertion 8mo ago
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 8mo 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 8mo 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 8mo ago
      You're making too much sense for a computer security specialist.
  - michaelt 8mo 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 8mo ago
      If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.
      - lazyasciiart 8mo ago
        Until any bad customer learns about the fail-open.
candiddevmike 8mo ago
Using something like npm-better-audit in your linting/CI allows you exclude devDependencies which cut down a ton of noise for us. IDGAF about vite server vulnerabilities.
junon 8mo ago
I maintain `debug` and the number of nonsense ReDoS vulnerability reports I get (including some with CVEs filed with high CVSS scores, without ever disclosing to me) has made me want to completely pull back from the JS world.
Twirrim 8mo ago
I've been fighting with an AI code review tool about similar issues. That and it can't understand that a tool that runs as the user on their laptop really doesn't need to sanitise the inputs when it's generating a command. If the user wanted to execute the command they could without having to obfuscate it sufficient to get through the tool. Nope, gotta waste everyone's time running sanitisation methods. Or just ignore the stupid code review tool.
- DecoySalamander 8mo ago
  There is a plausible scenario in which a user finds some malicious example of cli params for running your command and pasts it in the terminal. You don't have to handle this scenario, but it would be nice to.
  - estimator7292 8mo ago
    There is a plausible scenario where a user cuts their wrist open cooking dinner. You don't have to file the edge off cooking knives, but won't you think of the children?
    - DecoySalamander 8mo ago
      Kitchen knives actually do have safety features, such as non-slip handles and finger guards, which users appreciate. I certainly do. Users also appreciate safeguards in cli tools, such as not deleting all data if input happens to be slightly wrong. Sure, you could design your tool to be used exclusively by leet hackers, but the idea of sanitizing your inputs is not completely preposterous.
silverwind 8mo ago
ReDoS is a bug in the regex engine. Still, V8 etc. seem to refuse to provide a ReDoS-safe regex engine by default.
- ZiiS 8mo ago
  Is the possibility to write an infinite loop in your language of choice a bug?
  - talkin 8mo ago
    Most regex usage actually doesnt require near infinite backtracking, so limited unless opted in wouldn’t be that weird.

by nfm 8mo ago

adverbly 8mo ago

Seriously! We also suffer from this. Although in some cases it's due to a Dev dependency. It's crazy how much noise it adds specifically from ReDoS...

robszumski 8mo ago
Totally hear you on the noise…but we should want to auto-merge vs ignore, no? Given the right tooling of course.
- dotancohen 8mo ago
  No
- UqWBcuFx6NV4r 8mo ago
  We could just skip some steps and I could send you a zip file of malware for you to install on your infra directly if you’d like.
- deleted 8mo ago
  [deleted]
monkpit 8mo ago
ReDoS cves in your dev dependencies like playwright that could literally never be exploited, so annoying.

staticassertion 8mo ago

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 8mo 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 8mo 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 8mo ago
    You're making too much sense for a computer security specialist.
- michaelt 8mo 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 8mo ago
    If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.
    - lazyasciiart 8mo ago
      Until any bad customer learns about the fail-open.

candiddevmike 8mo ago

Using something like npm-better-audit in your linting/CI allows you exclude devDependencies which cut down a ton of noise for us. IDGAF about vite server vulnerabilities.

junon 8mo ago

I maintain `debug` and the number of nonsense ReDoS vulnerability reports I get (including some with CVEs filed with high CVSS scores, without ever disclosing to me) has made me want to completely pull back from the JS world.

Twirrim 8mo ago

I've been fighting with an AI code review tool about similar issues. That and it can't understand that a tool that runs as the user on their laptop really doesn't need to sanitise the inputs when it's generating a command. If the user wanted to execute the command they could without having to obfuscate it sufficient to get through the tool. Nope, gotta waste everyone's time running sanitisation methods. Or just ignore the stupid code review tool.

DecoySalamander 8mo ago
There is a plausible scenario in which a user finds some malicious example of cli params for running your command and pasts it in the terminal. You don't have to handle this scenario, but it would be nice to.
- estimator7292 8mo ago
  There is a plausible scenario where a user cuts their wrist open cooking dinner. You don't have to file the edge off cooking knives, but won't you think of the children?
  - DecoySalamander 8mo ago
    Kitchen knives actually do have safety features, such as non-slip handles and finger guards, which users appreciate. I certainly do. Users also appreciate safeguards in cli tools, such as not deleting all data if input happens to be slightly wrong. Sure, you could design your tool to be used exclusively by leet hackers, but the idea of sanitizing your inputs is not completely preposterous.

silverwind 8mo ago

ReDoS is a bug in the regex engine. Still, V8 etc. seem to refuse to provide a ReDoS-safe regex engine by default.

ZiiS 8mo ago
Is the possibility to write an infinite loop in your language of choice a bug?
- talkin 8mo ago
  Most regex usage actually doesnt require near infinite backtracking, so limited unless opted in wouldn’t be that weird.