6 ms·

Dan Abramov has an interesting take on npm audit (https://overreacted.io/npm-audit-broken-by-design https://overreacted.io/npm-audit-broken-by-design). Scannin

Dan Abramov has an interesting take on npm audit (https://overreacted.io/npm-audit-broken-by-design https://overreacted.io/npm-audit-broken-by-design). Scanning through the vulns on GitHub Advisory Database, it looks like it still contains many that DA brought up as unhelpful at best (e.g. “Regular Expression Denial of Service”).

seniorsassycat 5y ago
I've used esbuild's metadata file to filter npm audit's report and only warn for packages with files that are required at runtime. It's great at filtering out denial of service in the command line parser of my web server.
- mylesborins 5y ago
  This sounds SUPER interesting. Do you have an example of this? I wonder if this is something we could adopt in npm itself
  - seniorsassycat 5y ago
    https://github.com/everett1992/npm-esbuild-audit https://github.com/everett1992/npm-esbuild-audit
DeepYogurt 5y ago
I for one do like to know when I have a denial of service vector in my app.
- vorticalbox 5y ago
  Just because there is a cve in a dependancie does not mean its exploitable in context of your application. Say there was a regex dos in nodemon, I only use this for local development and has no effect on my main application. Point is npm audit is an advisory as it doesn't know the context in which it used.
  - DeepYogurt 5y ago
    > Just because there is a cve in a dependancie does not mean its exploitable in context of your application. Sure, but I'd rather be alerted to the issue so that I can investigate.
    - gherkinnn 5y ago
      Problem is, reacting to these alerts is a full time job. And when you’re faced with endless false positives you stop paying attention and eventually disable it.
      - ygjb 5y ago
        Then, if you build a successful product, you get: * ransomware * free PR from haveibeenpwned (but not the kind you want) * a burning desire to put my (or one of my AppSec/IR peers) kids through college. That said, YMMV.
        runnerup 5y ago
        I think we all agree with this. However, the semantics boil down to, if you use n: - with no advisory database/dependency scanning, you'll eventually suffer this parade of horribles - with an advisory database / dependency scanning which results in tons of false positives, you will also suffer from the same parade of horribles. A scanning system with relatively few false positives could change the result. But very very few groups can afford to follow up on all of these . And those which can tend to take ownership of their own dependencies, perhaps privately forking them (as Google did with Linux) Maybe dependency advisor will eventually grow into the role we want them to fill and become far more useful. It's probably better than nothing in its current form, but it's hard to say how much better than nothing.
      - kevin_thibedeau 5y ago
        Shouldn't there be a Node package where someone's opinion of what is a false positive gets automatically applied.
  - deleted 5y ago
- colechristensen 5y ago
  Many of these kinds of things are in places that could never actually result in a denial of service. There is a large problem with security reporting where people report issues which couldn’t ever be exploited and then scanning tools and up showing hundreds of “vulnerabilities” which don’t actually represent any danger.
  - DeepYogurt 5y ago
    I mean, you don't have to use the scanning tools if you'd prefer not to know.
    - Hallucinaut 5y ago
      The problem is it gets weaponized. If you're unlucky you have a client who runs a scan naively on your software and demands these get addressed as critical priorities under SLA. I'm sure there are plenty out there with managers who will just run the report and demand these "security issues" are fixed and won't understand an explanation on why it's not relevant.
      - bawolff 5y ago
        This is a silly objection in my opinion - clients demand unreasonable things all the time. Its up to you to write a reasonable SLA that protects yourself. Dont get me wrong, i wish npm audit was better. But unreasonable people will be unreasonable regardless of the tools they have access to.
    - colechristensen 5y ago
      It’s not about not wanting to know, it’s about wanting to know about real security issues and being buried in low quality reports which do not need to be addressed.
    - technion 5y ago
      The risk that a person could potentially write an infinite while loop and commit it to a codebase is about the same as the threat posed by the DoS "vulnerabilities" that seem to have completely overrun the NPM audit system. Noone wants to know about the former risk.
- bawolff 5y ago
  I think the bigger issue is when people rate ReDoS as higher severity than code execution vulns. But ultimately, vuln lists are just lists not magic. You still have to apply them to your context.
- TameAntelope 5y ago
  How do you feel about false positives?
- Floegipoky 5y ago
  This is kind of a long story but the short version is that the tooling isn't yet able to differentiate between dependencies which are packaged and deployed with your application vs dependencies which are only used in the build process. The canonical example seems to be regex DOS vulns reported in a test library. What does an "exploit" look like? One of my colleagues writes a bad regex in a test, now the test suite takes an offensively long amount of time to finish. That's not a vulnerability, that's a broken build. Even if they bypassed the automated tests and forced a deployment to production the offending regex would not be included.
  - d4mi3n 5y ago
    While I agree that regex DoS isn't a very useful thing to highlight in a build, there are risks that come with vulnerable code running in CI/CD systems. There's a whole topic in information security and infrastructure hardening that centers around SDLC (secure development lifecycle) and it covers such thrilling topics as: 1. Is the code from your SCM the same as the code that was built and deployed? 2. Has anyone tampered with your build or deployment artifact? 3. Who all actually has access to the boxes that do all this? Can you tell when folks access your build boxes and what has changed on them? 4. Does your CI/CD system have privileged access to secrets or other internal networks? 5. How confident are you that your digital supply chain is reliable and trustworthy? Would you know if someone fed you a poisoned dependency? The list goes on and on. There be dragons here. I'd love to see less focus on regex DoS and more awareness around the fact that build systems need just as much scrutiny and security as the production environments they feed into.
    - xyzzy123 5y ago
      People act like tooling that promotes useless busywork is "free security advice". It's actively harmful. Prioritising security activities that aren't useful (fixing "regex dos" in dev deps) takes time and effort that could have been spent on real bugs or product improvement.
      - kkirsche 5y ago
- onion2k 5y ago
  So do I, so when a tool tells me there's a ddos vector in a devdependency that never gets put on a live server I ignore it. If it happens a lot I start to ignore all those warnings. If that leads me to ignore a real warning then the warning has had a negative impact. If you ever heard the story of "The Boy Who Cried Wolf" as a child you should recognise what npm audit is doing wrong.
  - kkirsche 5y ago
    Your company may care about it. Endpoints are as common a vector for attacks as the server is. As a penetration tester, I’ve used DoS vectors before to make a developer think they needed their password to kill an app, and stole their credentials to then breach their other assets. If you think the server is all that matters, you are a good target in my eyes.
underwater 5y ago
The irony is that those useless "Regular Expression Denial of Service” alerts create their own denial of service attack against `npm audit` consumers.
- msdrigg 5y ago
  CVE-2021-41968 Npm audit denial-of-service by Regular Expressions Denial of Service CVE’s
lukeschlather 5y ago
Ultimately I think everyone will find more headaches trying to avoid updating than they would from updating. This sort of thing, even when the exact issue is nonsense, is still a helpful prod to let me know I'm using unsupported software.

seniorsassycat 5y ago

I've used esbuild's metadata file to filter npm audit's report and only warn for packages with files that are required at runtime. It's great at filtering out denial of service in the command line parser of my web server.

mylesborins 5y ago
This sounds SUPER interesting. Do you have an example of this? I wonder if this is something we could adopt in npm itself
- seniorsassycat 5y ago
  https://github.com/everett1992/npm-esbuild-audit https://github.com/everett1992/npm-esbuild-audit

DeepYogurt 5y ago

I for one do like to know when I have a denial of service vector in my app.

vorticalbox 5y ago
Just because there is a cve in a dependancie does not mean its exploitable in context of your application. Say there was a regex dos in nodemon, I only use this for local development and has no effect on my main application. Point is npm audit is an advisory as it doesn't know the context in which it used.
- DeepYogurt 5y ago
  > Just because there is a cve in a dependancie does not mean its exploitable in context of your application. Sure, but I'd rather be alerted to the issue so that I can investigate.
  - gherkinnn 5y ago
    Problem is, reacting to these alerts is a full time job. And when you’re faced with endless false positives you stop paying attention and eventually disable it.
    - ygjb 5y ago
      Then, if you build a successful product, you get: * ransomware * free PR from haveibeenpwned (but not the kind you want) * a burning desire to put my (or one of my AppSec/IR peers) kids through college. That said, YMMV.
      - runnerup 5y ago
        I think we all agree with this. However, the semantics boil down to, if you use n: - with no advisory database/dependency scanning, you'll eventually suffer this parade of horribles - with an advisory database / dependency scanning which results in tons of false positives, you will also suffer from the same parade of horribles. A scanning system with relatively few false positives could change the result. But very very few groups can afford to follow up on all of these . And those which can tend to take ownership of their own dependencies, perhaps privately forking them (as Google did with Linux) Maybe dependency advisor will eventually grow into the role we want them to fill and become far more useful. It's probably better than nothing in its current form, but it's hard to say how much better than nothing.
    - kevin_thibedeau 5y ago
      Shouldn't there be a Node package where someone's opinion of what is a false positive gets automatically applied.
- deleted 5y ago
colechristensen 5y ago
Many of these kinds of things are in places that could never actually result in a denial of service. There is a large problem with security reporting where people report issues which couldn’t ever be exploited and then scanning tools and up showing hundreds of “vulnerabilities” which don’t actually represent any danger.
- DeepYogurt 5y ago
  I mean, you don't have to use the scanning tools if you'd prefer not to know.
  - Hallucinaut 5y ago
    The problem is it gets weaponized. If you're unlucky you have a client who runs a scan naively on your software and demands these get addressed as critical priorities under SLA. I'm sure there are plenty out there with managers who will just run the report and demand these "security issues" are fixed and won't understand an explanation on why it's not relevant.
    - bawolff 5y ago
      This is a silly objection in my opinion - clients demand unreasonable things all the time. Its up to you to write a reasonable SLA that protects yourself. Dont get me wrong, i wish npm audit was better. But unreasonable people will be unreasonable regardless of the tools they have access to.
  - colechristensen 5y ago
    It’s not about not wanting to know, it’s about wanting to know about real security issues and being buried in low quality reports which do not need to be addressed.
  - technion 5y ago
    The risk that a person could potentially write an infinite while loop and commit it to a codebase is about the same as the threat posed by the DoS "vulnerabilities" that seem to have completely overrun the NPM audit system. Noone wants to know about the former risk.
bawolff 5y ago
I think the bigger issue is when people rate ReDoS as higher severity than code execution vulns. But ultimately, vuln lists are just lists not magic. You still have to apply them to your context.
TameAntelope 5y ago
How do you feel about false positives?
Floegipoky 5y ago
This is kind of a long story but the short version is that the tooling isn't yet able to differentiate between dependencies which are packaged and deployed with your application vs dependencies which are only used in the build process. The canonical example seems to be regex DOS vulns reported in a test library. What does an "exploit" look like? One of my colleagues writes a bad regex in a test, now the test suite takes an offensively long amount of time to finish. That's not a vulnerability, that's a broken build. Even if they bypassed the automated tests and forced a deployment to production the offending regex would not be included.
- d4mi3n 5y ago
  While I agree that regex DoS isn't a very useful thing to highlight in a build, there are risks that come with vulnerable code running in CI/CD systems. There's a whole topic in information security and infrastructure hardening that centers around SDLC (secure development lifecycle) and it covers such thrilling topics as: 1. Is the code from your SCM the same as the code that was built and deployed? 2. Has anyone tampered with your build or deployment artifact? 3. Who all actually has access to the boxes that do all this? Can you tell when folks access your build boxes and what has changed on them? 4. Does your CI/CD system have privileged access to secrets or other internal networks? 5. How confident are you that your digital supply chain is reliable and trustworthy? Would you know if someone fed you a poisoned dependency? The list goes on and on. There be dragons here. I'd love to see less focus on regex DoS and more awareness around the fact that build systems need just as much scrutiny and security as the production environments they feed into.
  - xyzzy123 5y ago
    People act like tooling that promotes useless busywork is "free security advice". It's actively harmful. Prioritising security activities that aren't useful (fixing "regex dos" in dev deps) takes time and effort that could have been spent on real bugs or product improvement.
    - kkirsche 5y ago
onion2k 5y ago
So do I, so when a tool tells me there's a ddos vector in a devdependency that never gets put on a live server I ignore it. If it happens a lot I start to ignore all those warnings. If that leads me to ignore a real warning then the warning has had a negative impact. If you ever heard the story of "The Boy Who Cried Wolf" as a child you should recognise what npm audit is doing wrong.
- kkirsche 5y ago
  Your company may care about it. Endpoints are as common a vector for attacks as the server is. As a penetration tester, I’ve used DoS vectors before to make a developer think they needed their password to kill an app, and stole their credentials to then breach their other assets. If you think the server is all that matters, you are a good target in my eyes.

underwater 5y ago

The irony is that those useless "Regular Expression Denial of Service” alerts create their own denial of service attack against `npm audit` consumers.

msdrigg 5y ago
CVE-2021-41968 Npm audit denial-of-service by Regular Expressions Denial of Service CVE’s

lukeschlather 5y ago

Ultimately I think everyone will find more headaches trying to avoid updating than they would from updating. This sort of thing, even when the exact issue is nonsense, is still a helpful prod to let me know I'm using unsupported software.