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

81–90 of 268 posts

Re: Npm Audit: broken by design?

#81

Post by nkozyra »

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.

Right, but that's why I wrote "context," and seems to be the primary complaint in this article.

Re: Npm Audit: broken by design?

#82

Post by dj_mc_merlin »

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

1. You wouldn't wait for a full build in that scenario, but deploy a known-good last image or emergency shut down.

2. If you are doing a full build and fail because of the regex DOS, then that build would also contain the attacker injected siphoning code, which would make your entire exercise futile in the first place

3. Not obviously messing with the network or crashing build machines would be a better way of siphoning data for longer.

4. This is very contrived.

Re: Npm Audit: broken by design?

#83

Post by prionassembly »

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?

Re: Npm Audit: broken by design?

#85

Post by theptip »

jrochkind1 wrote: post #65

> Inline all dependencies during publish… From a maintainer’s point of view, the upsides are clear: you get faster boot time, smaller downloads, and — as a nice bonus — no bogus vulnerability reports from your users. And when you inlined a version that later really does have a vulnerability, it is not easily flagged or fixed by your consumers. The tension between "upgrades (especially of indirect dependencies) might…

> I'm not totally sure why they are so insane

I think a big part of it is that due to much stronger pressure on bundle size than most other environments, each library tends to be small, so there have to be more to carry the same amount of functionality.

Duplicates are certainly a contributing factor as well, and small bundles compound with allowed-duplication to further increase the tree size. I think that small package size also probably makes it harder to require a single version for each dep, since there are going to be more edges in the graph and therefore more relations for library maintainers to keep track of (including what would in other languages be intra-package requirements), so you're more likely to get version incompatibilities.

Re: Npm Audit: broken by design?

#86

Post by trunnell »

askmike wrote: post #80
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.…

> 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 to make a fraudulent commit. Given how easy most teams make it to commit code, this isn’t too high of a bar.

Re: Npm Audit: broken by design?

#87

Post by bscphil »

mrweasel wrote: post #62
quintex wrote: post #6

As someone who only had just gotten into front end programming after years of backend work, npm has been a nightmare. I haven't experienced the same level of frustration with other package managers (pip, cargo, go mod, etc) as I have with npm. Is yarn the better option? What is our path forward?

I basically do no frontend development, partly due to tools npm and the current frameworks, I simply cannot wrap my head around it. I do help run a few modern javascript application however. Even a minimal app will pull in 1000+ dependecies, and I think that’s the problem. It simply don’t happen in Python, Go or Rust (or even Java) because the languages comes with a rich standard library. Javascript comes with just t…

> Rust

This has not been my experience at all. Most Rust developers unfortunately seem quite happy to adopt modern programming bad practices. (There are many exceptions, of course.)

Example: I went with the first Rust program I could find installed on my computer, tealdeer. It's a dead simple program: run `tldr progname` and it will print a handful of examples of how to run `progname` in your terminal. Run `tldr --update` and it will download the latest version of the database containing these examples from a web server.

To build this extremely basic CLI program, I need ONE HUNDRED AND NINETEEN distinct crates.

Re: Npm Audit: broken by design?

#88

Post by trey-jones »

G3rn0ti wrote: post #76
cratermoon wrote: post #55

Earlier quoted context omitted.

Beautifully succinct. This quote: "Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims." Alignment of incentives is messed up. Goodhart-Strathern's and Campbell's laws apply.

Maybe then writing and submitting a CVE should cost some money that’s payed back together with the reward if the vulnerability is found to be „reasonable“ upon review?

Maybe, but you risk swinging too far in the opposite direction into under-reporting of vulnerabilities.

Re: Npm Audit: broken by design?

#89

Post by killion »

I like his point about `npm audit --production` being a good way to cut down the noise. But Github doesn't seem to take dev dependencies into account when sending security alerts. I get emails about non-issues from them all the time.

Re: Npm Audit: broken by design?

#90

Post by solatic »

> Inlining dependencies kind of goes against the whole point of npm

I mean, this is why people love language with deep, solid standard libraries. You don't have a situation where a problem in a sub-sub-sub-sub-dependency provokes five different groups of people to all issue an update, one after another. You just upgrade your underlying installation to the latest patch version and continue.

Language ecosystems where a few lines of code constitutes a library fundamentally result in you being dependent on a huge number of outside people to cooperate on updates. That's what's broken. Not a tool which tells you that you have out-of-date libraries and, by the by, hooks into CVE databases.

OP should stop and consider whether it might be beneficial to inline some of those dependencies before dismissing it out-of-hand. If you never use the dependency in such a way as to present a real security risk... and you don't need feature updates from upstream, i.e. the software is fine as-is when you first incorporated the dependency... then why wouldn't you inline the dependency?

If anything, inlining the dependency will allow static code analyzers to point out all the parts of the dependency which you're not using (i.e. dead code) and eliminate it all. That way, even if the dependency were to be discovered to have a security fault, if the faulty code was in a section that you eliminated as dead code... then you don't have a security problem in the first place!

Post reply on HN