Npm Audit: broken by design? • Hacker News Board

Re: Npm Audit: broken by design?

#211

Post by enneff » Thu, Jul 08, 2021, 1:49 AM UTC

hinkley wrote: post #208

marcosdumay wrote: post #108

Earlier quoted context omitted.

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 th…

The feature I missed about Subversion was, if you could figure out how to treat your code like a proper tree, individual teams would check out one, maybe two directories, and only the leads and operational people ever had the whole thing. I never entirely understood what it was in subversion's internals that prevented it from being used as a DCVS. We could figure out version numbers with branches and multiple repos.…

Revisions in Subversion are identified by a monotonically increasing number. How can you distribute that?

Re: Npm Audit: broken by design?

#212

Post by jeroenhd » Thu, Jul 08, 2021, 2:02 AM UTC

efitz wrote: post #175

Writing my comments in the snarky tone of the article. So the article boils down to “a bunch of these vulnerabilities aren’t applicable to my app which is built using a specific NPM package”. Congratulations. Welcome to the world of practical information security. As a security engineer, we’re lucky if your favorite package manager even associates vulnerability information with your packages. Never mind that you’re p…

In my opinion, most of these vulnerabilities are completely useless. A React developer performing a DoS on themselves or their build servers with a complex regex is theoretically a problem, but in practice I'd rate it below "low" importance. If a developer wants to ruin a company with huge building costs, why not add a cryptominer to the build process? Why not just spawn hundreds of build tasks? Why bother with generating complex regexes as an attack vessel when you have access to the code?

I'm not even sure if I'd classify it as a security bug at this point, I'd just classify these examples as configuration options to be aware of. Document and ignore.

With the explosion in Javascript packages to implement trivial behaviours, the NPM dependency hell and all the other cruft that "modern" frontend development requires, there are more important security issues to monitor.

Many real issues exist, but their classification is ridiculously flawed. Every security researcher tries to mark their vulnerability up to be the next Eternal Blue of Javascript development, but these vulnerabilities rarely matter.

I think a much bigger problem from a security standpoint is not necessarily the quality of these bug reports, but the sheer number of dependencies even a basic React project has these days. Supply chain attacks are real and the javascript world can do with some dependency purging. Any of the 200 single-line Javascript libraries can be compromised at any point and infect developers all over the world the next time they update their dependencies.

The way people "just" seem to add new dependencies to projects terrifies me. left-pad hit the frontend world and changed nothing. twilio-npm infected developer machines, and create-react-app imports over 1500 libraries as if it's the most normal thing in the world. It's absolute madness.

I have no idea how to fix all of this. It's only a matter of time before someone replicates the research people have done in uploading packages with typos in the name (which have reached into big, famous companies like Apple and Facebook) and start doing some serious damage. Maybe it's already happening: a package having been taken over for scraps, the owners lying in wait while everyone downloads and updates their React/Svelte/etc. packages, ready with their cryptolockers to strike frontend devs and build servers the world over with the push of a button. I wouldn't be surprised, not in the slightest.

Re: Npm Audit: broken by design?

#213

Post by [deleted] » Thu, Jul 08, 2021, 2:04 AM UTC

efitz wrote: post #201

overgard wrote: post #178

Earlier quoted context omitted.

The point is that if the feature is going to constantly produce false positives, it's useless. I concur with the author, I never check those warnings anymore.

It’s not a false positive, as described. It’s “mitigated by environment”. The vulnerability is real. The severity is arguably too high. People throw around “false positive” as a catch-all for “I don’t care about this”. But there are a number of distinct reasons one might not care: - the scanner is wrong (e.g. there’s a code bug in the scanner like detecting “printed” instead of “sprintf”. - the output is wrong becaus…

[deleted]

Re: Npm Audit: broken by design?

#214

Post by jeroenhd » Thu, Jul 08, 2021, 2:33 AM UTC

TechBro8615 wrote: post #127

gentleman11 wrote: post #43

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?

The reason it’s so big is because it’s your build chain. I’ve always found this criticism of JS annoying – you’ve also got to pull in a few hundred MB of tooling for C++, Java, or Rust — it’s just that in the JS case, the “compiler” is usually per project.

In my experience, Java and Rust have the exact same problem. The nature of the dependencies is different, though; in Rust or Java, you'll have dependencies that handle a protocol, set up something like TLS, manage state, that kind of thing. In Javascript, you'll have a single dependency that provides a single function that does a recursive file search, or a dependency like is-number that checks if a variable is a number.

Javascript seems to prefer millions of tiny dependencies of thousands of larger libraries, which is a choice that can be defended. The difference is not necessarily one in lines of code or binary size, but one in amount of vendors trusted. Many libraries also handle trivial code that (in my opinion) should be part of the programming language or basic developer knowledge already. The is-something packages that fill Javascript dependency trees to the brim can only be considered as failings of the language in my opinion.

As a developer, I trust parties like webpack, gulp, and Facebook, but I haven't heard about jonschlinkert (nothing against him, just a random name I picked) and I don't know who maintains is-number, is-path-cw, is-path-in-cwd, is-path-inside or path-is-inside and how reliable they are. All of these dependencies seem like excellent methods in a library, but they all could've been part of a single dependency no more than 60 lines of code in length. Many NPM packages feel less like libraries and more like automated StackOverflow answers. Adding a vendor to your supply chain for just 40 lines of open source code is just inefficient; why risk trusting yet another vendor to not inject malware in the future like this?

The Java world has some popular names like Apache, Google and Jetbrains that maintain large libraries so it's easy to build a chain of trust. Rust is moving the Javascript way, with hundreds of megabytes of dependencies from thousands of individual repositories, but at least most of its packages add something nontrivial.

C++ doesn't have a package manager, at least not in the same way other languages do. C++ libraries usually come from very specific toolkits or single sources (like Linux package managers). There's tons of packages for C++ development, but all of them are kept up to date by a single organisation on my machine.

Re: Npm Audit: broken by design?

#215

Post by thaumasiotes » Thu, Jul 08, 2021, 2:35 AM UTC

staticassertion wrote: post #195

DaiPlusPlus wrote: post #188

Earlier quoted context omitted.

> You fixed it, one less bug to worry about. Those "bugs" can be features though - or the work involved to fix the bug meant that high-impact feature work - or other bugfixes, had to be postponed or even cancelled. Our SaaS frequently gets security "researchers" (read: people running online scanners) submitting emails through our contact-form informing us about click-jacking attacks on our login-page - the problem fo…

> so there is no easy solution that makes the "I ran a tool, gimme $100" people go-away without causing a much bigger problem to now exist. Maybe consider setting up a free-tier HackerOne bounty program? I think they triage to some degree on your behalf.

In the free tier? Triage is a paid service.

Re: Npm Audit: broken by design?

#216

Post by winrid » Thu, Jul 08, 2021, 2:49 AM UTC

mikewhy wrote: post #176

j1elo wrote: post #121

I guess we could have a documentary series! Next up, npm link: broken by design Synopsis of the chapter: A command with broken behavior that has been reported since as early as 2015, but that "got lost" every time the winds changed and the project decided to change where to manage bugs. What will happen in the latest attempt from an affected user? Tune in and be ready for an exciting ride! https://github.com/npm/cli/…

Funny, because Yarn does do what you expect here and I absolutely loathe it.

What's to loathe about Yarn? I only used it briefly buy in comparison to NPM there were less surprises.

Re: Npm Audit: broken by design?

#217

Post by taurath » Thu, Jul 08, 2021, 2:50 AM UTC

krainboltgreene wrote: post #209

junon wrote: post #137

Earlier quoted context omitted.

I'm a maintainer of a few of the larger packages on npm. This is generally pretty accurate. Snyk Security seems only to find regex DoS bugs and I'm a bit disappointed in them being classified as high severity, and they're the only ones submitting reports right now. They seem pretty adamant on filing CVEs despite what the owner says (It's normally fine but these DoS vulns require very large input to be handed into the…

> Super broken, everything related to npm's package lock stuff is broken by design. I've been saying it for years now and it seems people still cling to blindly trusting what corporations say. Because this isn't true. Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. These Regex issues should be fixed, libraries should update to safe versions, thin…

Read as: tough, that company says you need to do the work so I demand you do the work.

Re: Npm Audit: broken by design?

#218

Post by earthboundkid » Thu, Jul 08, 2021, 3:10 AM UTC

hinkley wrote: post #203

j1elo wrote: post #121

I guess we could have a documentary series! Next up, npm link: broken by design Synopsis of the chapter: A command with broken behavior that has been reported since as early as 2015, but that "got lost" every time the winds changed and the project decided to change where to manage bugs. What will happen in the latest attempt from an affected user? Tune in and be ready for an exciting ride! https://github.com/npm/cli/…

npm has been buggy for so long that it is actively driving me away from NodeJS. I would like to wait to see if the rearchitecture for npm 7 actually allows them to test for regressions more productively, but at this point I don't know if I have the stamina to wait for my company to migrate to node 16. Someone offers me a job doing Elixir or non-webapp stuff and I'm out. Probably permanently.

Node is the new IE.

Re: Npm Audit: broken by design?

#219

Post by junon » Thu, Jul 08, 2021, 3:22 AM UTC

krainboltgreene wrote: post #209

junon wrote: post #137

Earlier quoted context omitted.

I'm a maintainer of a few of the larger packages on npm. This is generally pretty accurate. Snyk Security seems only to find regex DoS bugs and I'm a bit disappointed in them being classified as high severity, and they're the only ones submitting reports right now. They seem pretty adamant on filing CVEs despite what the owner says (It's normally fine but these DoS vulns require very large input to be handed into the…

> Super broken, everything related to npm's package lock stuff is broken by design. I've been saying it for years now and it seems people still cling to blindly trusting what corporations say. Because this isn't true. Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. These Regex issues should be fixed, libraries should update to safe versions, thin…

> Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken.

I've been in the node scene since 0.10. That's around 10 years. My packages have billions of downloads annually. My viewpoint here carries the weight of hours of debug time and frustration and confused users of my code, as well as meeting and knowing the npm staff at the time quite personally, and knowing under which circumstances package lock files were implemented.

They are broken.

> These Regex issues should be fixed

They do, pretty much immediately after they're reported.

> libraries should update to safe versions

I check all the version ranges of dependent libraries when I push a patch with vuln fixes. They get pulled just fine without needing to update every single package. This is what version ranges are for.

> things should advance

Yes but this is nebulous and vague and aside from the point.

> and any incentive we have we should use to make this happen.

I don't see where the disagreement is. This is exactly what happens all the time, nothing is the problem here. I don't get your point.

---

Package lock files were designed in a few short days and pushed out prematurely without much review by a single Npm employee (at the time) since they promised it for the v5 release. They were on a time crunch because they were trying to keep with Node.js's next major release timeline, which operates independently of npm's (at least, that's how it was conveyed to me).

So this change got pushed out, had an absolute mountain of bugs that took ages to fix (e.g. at one point adding a new dependency would delete your entire node_modules folder), and promised added security when in reality they do nothing of the sort.

Instead, they cause subtle caching-related bugs, they add an artifact to source control (which is always code smell in my book), crap up diffs/PRs, cause headaches across platforms, and do very little to help... anything, really.

They're super, super broken by design. Yet npm tells you you need them ("please commit this to your repository") and refuses to do basic security things without them (npm audit).

So why were they added? IIRC it was because the version resolution was a massive strain on npm's servers, so lockfiles removed the need to fetch tons of version information each time you added another dependency.

Oh, and don't even begin to whine about them on Twitter (at the time), lest you be yelled at by the implementor for being ignorant or something.

It was a shit show. They add absolutely nothing to the industry.

Re: Npm Audit: broken by design?

#220

Post by lmm » Thu, Jul 08, 2021, 3:25 AM UTC

JonathonW wrote: post #46

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…

Other developers have no idea of context either. Unless you have a way of enforcing that certain code is never exposed to user input (and I agree that a build-time-only dependency does solve that), sooner or later it will be.

Accepting regexes from user input is a really insidious class of bug that can go undetected for years. I've seen real outages caused by it, so it's absolutely worth doing something proactive about.