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

41–50 of 268 posts

Re: Npm Audit: broken by design?

#41

Post by cphoover »

danabramov wrote: post #14
cphoover wrote: post #11

Vulnerabilities are just code paths that can behave in unexpected ways and be abused.... I'm not sure the author's point, that development configuration could not hide malicious code? Why not? All NPM does is scan to the dependency graph for vulnerability reports, it doesn't make any assessment of your consuming application's use-case. If you don't find this useful that is fine, don't use it. I think it's totally wor…

> I'm not sure the author's point, that development configuration could not hide malicious code? Why not? Quite the opposite! Quoting the article: As any security professional will tell you, development dependencies actually are an attack vector, and perhaps one of the most dangerous ones because it’s so hard to detect and the code runs with high trust assumptions. This is why the situation is so bad in particular: a…

All it does is look to see if either your direct dependencies or descendant dependencies exist in the advisory database....

It seems like a simple algorithm that works pretty well. Perhaps ignoring certain dependencies makes sense, via an ignore list.

I just find the title "NPM is broken by design" to be a little hyperbolic, when it seems like the complaint is that it's tedious removing all the low-quality dependencies from your project. node security/npm-audit has at least increased the conversation around security for many around the npm ecosystem, where there wasn't much-if-any discussion prior. I think they deserve credit for this.

EDIT: I'm not sure why I'm being downvoted.

Re: Npm Audit: broken by design?

#42

Post by jgerrish »

Correct me if I'm wrong.

But, one of the goals in software engineering right now is reproducible builds. This means building from source. And of course we'll want to automate that. We've already made inroads with CI

So, correct me if I'm wrong, these are still vulnerabilities.

Tragedy of the commons stuff.

This article might be honest. But I hope in the future we don't need devil's advocate arguments.

Re: Npm Audit: broken by design?

#43

Post by gentleman11 »

npm is a bit nuts on its own. I started learning react this year and the course I'm taking had me install that create react app module or similar. It dragged in 1700 dependencies, and the folder for a hello world app was almost 90mb iirc. How can you possibly pretend you have any control over your app or it’s security in that situation?

Re: Npm Audit: broken by design?

#44

Post by zinekeller »

cratermoon wrote: post #34
esens wrote: post #29

I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…

This kind of nonsense really goes back to the broken CVE process. https://opensourcesecurity.io/2021/03/30/its-time-to-fix-cve... Linux kernel maintainer Greg Kroah-Hartman has a similar opinion. https://github.com/gregkh/presentation-cve-is-dead/blob/mast... Edit: LWN mention https://lwn.net/Articles/801157/

The view of SQLite developers on CVEs is also dim: https://www.sqlite.org/cves.html

Re: Npm Audit: broken by design?

#45

Post by three14 »

_fob_ wrote: post #36

Indeed, npm is not aware of the context of the vulnerabilities. That does not invalidate them, however, and mean they should be hidden. I've worked in offensive security for quite long enough (been a dev for 10+ years before) to tell you that your context, or the most common one, isn't all that exist and someone's going use it the way it makes the app vulnerable. Based on the article's example, someone's going to bui…

A lot of these cases that npm reports are denial of service vulnerabilities (and marked high risk!). I just tried it on a project I have, and 11 out of 15 are DOS vulnerabilities in code that I run locally. When the normal user is using a project only locally, and the issue is DOS, it's hard to argue "but maybe someone will eventually put it online" and therefore I need to drop what I'm doing and patch my dependencies. (Yes, sometimes that would be the only way to satisfy npm, since the semver rules prevent it from fixing things automatically.)

Re: Npm Audit: broken by design?

#46

Post by JonathonW »

esens wrote: post #29

I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…

A regex "denial of service" "vulnerability" could be important, if it shows up in code that processes untrusted input from end users.

But NPM Audit has no idea of context-- a "critical" bug in `browserlist`, which, in this context, is never used outside the development process and never takes input outside of what's in my package.json, gets the same prominence (or more so, since it's early in alphabetical order) as a "critical" bug in Express, potentially allowing my server to be compromised.

I'm not really sure what the solution is here; NPM's just a package manager and doesn't know how you're using a given package. A simple heuristic distinguishing development dependencies and runtime dependencies in NPM Audit might be a start, but that doesn't help with situations like create-react-app's react-scripts where everything, runtime or dev dependency, is a transitive dependency of one package declared as a runtime dependency.

Re: Npm Audit: broken by design?

#48

Post by jgerrish »

jgerrish wrote: post #42

Correct me if I'm wrong. But, one of the goals in software engineering right now is reproducible builds. This means building from source. And of course we'll want to automate that. We've already made inroads with CI So, correct me if I'm wrong, these are still vulnerabilities. Tragedy of the commons stuff. This article might be honest. But I hope in the future we don't need devil's advocate arguments.

Still, the original post might inspire realignment of bug fixing incentives.

Re: Npm Audit: broken by design?

#49

Post by cratermoon »

lxe wrote: post #23

I agree with the author. Just like them, I only write code without any bugs that can be affected by the "vulnerabilities". I also never commit to upstream so others won't be able to edit my code. All my projects only run on my machine (which is of course also absolutely exploit-free and it's not connected to the internet).

You're being snarky, which is fine, but the author addresses that. If you're compromised, the attacker is not going to dig through your development folder to inject a regex that makes your build slow. They'll exploit privilege escalation bugs to install a bitcoin miner, ransomware, a DDOS bot node, or use some other vulnerability to grab and/or exploit your secrets. They'll do it the most direct way possible, not via some half-broken regex parser.

Re: Npm Audit: broken by design?

#50

Post by city41 »

mbesto wrote: post #13

> this “vulnerability” is absurd in this context Yes that's exactly the point. The audit tool has no awareness of the context and nor do the people who create severities. If severities were absolute then there would be no reason for anyone to review them. You would simply upgrade your libraries and be done with it, but that can't always be achieved nor may make business sense. I do agree with the author's note about…

I do think he makes a valid point towards the end though. create-react-app, and projects like it, get a lot of bug reports about these vulnerabilities. It's a lot of energy dedicated to something that ultimately isn't that important if you understand the context. I can understand the frustration.
Post reply on HN