Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm Audit: broken by design?

overreacted.io

Post reply on HN
Print view View original

101–110 of 268 posts

Re: Npm Audit: broken by design?

#101

Post by smsm42 »

trunnell wrote: post #74

A lack of imagination by the author, unfortunately... A DoS on your build machine and dev machine can be indeed be critical issues. Imagine this scenario: Your source code is somehow compromised and attackers slip in rogue code to your production site. It siphons off passwords or other PII. The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the problem.…

I think if the attacker got as far as deploy their code in your CI/CD pipeline and prod system, there's no "quickly" fixing it. There's a full shut down, restoring from trusted backup, full data and code audit and a lot of pain in the future validating and restoring the code and the data. Quick rebuild is not something that would be your priority there - how do you know this quick build won't be compromised anyway? If somebody got into your internal systems on the level they could modify the code, it's not a 1 minute problem and not a 5 hours problem, it's much bigger...

Re: Npm Audit: broken by design?

#103

Post by [deleted] »

esens wrote: post #60
nkozyra wrote: post #59

Earlier quoted context omitted.

> A regex "denial of service" "vulnerability" could be important, if it shows up in code that processes untrusted input from end users. But in this context what's the end result? Chrome locking up on the end user's (attacker's) machine? Again, an "attacker" doesn't have access to the source code for distribution. By inputting bad regexp data they're only DOSin themselves, no?

Could be in a service on a server, which in this case a RegEx DOS could lock the server for all users.

[deleted]

Re: Npm Audit: broken by design?

#104

Post by AaronFriel »

For those hoping to run npm audit in your CI/CD pipeline, I recommend this tool from IBM: https://github.com/IBM/audit-ci

In highly regulated industries, shipping code flagged as having a vuln without a manual approval could be a liability.

This wrapper around npm takes an allowlist argument, and our procedure is for an engineer to review the failing build, determine if the vulnerability (ugh, usually regex ddos or prototype pollution) is present in code that runs only at build time with trusted inputs, only on the client which is by definition untrusted, or in our webserver which takes in untrusted input.

As long as it's either of the first two, we document it in a commit and comment and redeploy. It's annoying, but it's far better than npm audit forcing a fix.

Re: Npm Audit: broken by design?

#105

Post by SOLAR_FIELDS »

prionassembly wrote: post #83
esprehn wrote: post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?

Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo.

You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...

Re: Npm Audit: broken by design?

#106

Post by dane-pgp »

x0x0 wrote: post #64
esprehn wrote: post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

We also wanted to use npm audit in our CI process so, instead of humans being careful, we could assert any known CVE stops a staging or prod deploy. Very annoyingly, npm audit doesn't have ignore functionality, at least when I was last forced to use it. I had to hack something together with bash scripts. For vulnerabilities that we determined weren't an issue ever (vuln in frontend framework we didn't use), or weren'…

> Very annoyingly, npm audit doesn't have ignore functionality

I can't believe no one here has mentioned the fantastic tool "better-npm-audit" which can be included as an npm dependency[0] and lets you add specific vulnerabilities to an ignore list.

The ignore list is actually a JSON config file stored alongside package.json in the repo, so only one developer ever needs to see the npm audit warning and can mute it for everyone else (after getting their PR approved).

Even better, the config file lets you specify an expiry date for each entry in the ignore list, and provide a note, such as a link to the upstream issue being worked on, so that you can periodically be reminded to go back and check if a new version is available which can give more confidence that your code really isn't affected.

I think that developers might have to be instructed to use the "--no-audit" option to "npm install" if they don't want to see the (false positive) warnings that the default behaviour produces, and that's a bad habit to learn if not all projects they work on are using "better-npm-audit". I don't know if there is a way to make that option the default on a per-project basis.

[0] https://www.npmjs.com/package/better-npm-audit

Re: Npm Audit: broken by design?

#107

Post by [deleted] »

mmis1000 wrote: post #38
gampleman wrote: post #3

We basically run it in CI... and then allow it to fail without failing the build. ¯\_(ツ)_/¯ It seems like a lot of this has been designed for Node (backend) development, whilst ignoring the fact that NPM is probably used more heavily for front-end development at this point.

Yep, some vulnerable package isn't even in the compile output. How a dev server that only binds to 127.0.0.1 a serious DOS problem? Who on the earth will want to DOS that?

[deleted]

Re: Npm Audit: broken by design?

#108

Post by marcosdumay »

prionassembly wrote: post #83
esprehn wrote: post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?

They do not use an usual git repository. Companies using monorepos have tools to restrict people's access to parts of it, and filter log noise.

Or, in other words, it's not that insanely complicated, because they have tools that make it look a lot like multiple repositories. And the large companies using multiple repositories have tools that make them look just like those monoreps. And HN has all those interesting threads full of people saying why one is better than the other.

Re: Npm Audit: broken by design?

#109

Post by trunnell »

smsm42 wrote: post #101
trunnell wrote: post #74

A lack of imagination by the author, unfortunately... A DoS on your build machine and dev machine can be indeed be critical issues. Imagine this scenario: Your source code is somehow compromised and attackers slip in rogue code to your production site. It siphons off passwords or other PII. The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the problem.…

I think if the attacker got as far as deploy their code in your CI/CD pipeline and prod system, there's no "quickly" fixing it. There's a full shut down, restoring from trusted backup, full data and code audit and a lot of pain in the future validating and restoring the code and the data. Quick rebuild is not something that would be your priority there - how do you know this quick build won't be compromised anyway? I…

I think the typical scenario is that you understand how big of problem it is only in retrospect.

In the moment, your first thought is that there is some type of quick fix that will restore functionality (if your site is down) or evict the intruder if something funny is detected. As a sibling commenter said, most teams would try to deploy a previous known-good build asset.

But I stand by my point that a DoS of a development system can indeed be critical! I’m surprised to find that I appear to be in the minority here...

Re: Npm Audit: broken by design?

#110

Post by nirvdrum »

trunnell wrote: post #86
askmike wrote: post #80

Earlier quoted context omitted.

> Your source code is somehow compromised and attackers slip in rogue code to your production site. Really at this point it's too late to do anything else, instead of trying to dos your dev machine he can instead do simpler things like delete your ssh key from the machine. But let's play along: > The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the pro…

I see your point that even worse things can happen when dev machines are compromised. The point I tried to make is that even a DoS of your machine can be a big problem. > There is nothing any attacker can do with the static files on the server that will trigger a RegEx DoS... IIUC, an attacker could change my package.json to include inputs to browserlist that trigger a RegEx DoS. To do that, the attacker only needs t…

If you, as an attacker, are going to make a fraudulent commit and change package.json, you could just pull in a bogus dependency or add a new script/command that gets run on the build/dev machine. I agree the bar to submitting a fraudulent commit is unfortunately too low for many teams. But, this also extends to package publishing, too.

We've seen packages published through compromised dev keys or the maintainer granted a new bad actor rights to publish. Here we could envision a situation where someone reports a legitimate, but low impact, security issue and also publishes a bogus package that everyone is now upgrading to. On the whole, these messages aren't encouraging people to upgrade to a new, verified release (i.e., a fixed version). They're encouraging people to upgrade to the latest release. Even if you suspend the bad actor thought experiment, the latest release of a package in all likelihood hasn't been audited beyond ensuring the previously reported security issue has been addressed. Upgrading indiscriminately is a risky activity as well. I don't think we should be encouraging people to do that (in any language ecosystem).

It's not lack of imagination of attack vectors at play here. Treating extremely low risk factors as if they're high priority reduces trust in the system as a whole. Getting developers to care more about security is a laudable effort, but I think the `npm audit` approach (as reported in the post) is going to encourage bad practices.

Post reply on HN