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

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

Post reply on HN
Print view View original

121–130 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#121

Post by TiddoLangerak »

brunoborges wrote: post #80
cluckindan wrote: post #59

Earlier quoted context omitted.

How does that protect against credential theft? MFA required to sign published releases?

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

You're missing the biggest root cause though, and that significantly hinders how well this translates between languages: the Java community has settled on fewer but large monolithic dependencies, whereas the JavaScript community has settled on many but small composable dependencies (for good historical reasons, but that's a topic in and off itself).

This directly influences how well e.g. version pinning works. In the Java world, package versions are _relatively_ independent from eachother and have few transitive dependencies, and as such version conflicts are relatively rare. This means you can get away with full pinning of all dependencies, with the occasional manual override of a conflicting transitive dependency.

This doesn't work in JavaScript. The dependency ecosystem is massively intertwined, if every library would specify exact versions you'd end up with literally hundreds of conflicts to resolve. That's not feasible. As a result, they've chosen the middle ground of using lock files in addition to version ranges.

This also hurts the effectiveness of verified namespaces: when packages come from hundreds of different sources, you're not going to notice 1 or 2 sketchy ones in there.

Other consequences of the big monolithic packages in Java are that updates tend to be less frequent, and more often from large reputable venders. Both of these help to reduce the problem too.

While the JavaScript toolchain can definitely learn a lot from the Java toolchains, the problems it needs to solve are not the same, and thus solutions don't translate 1-1.

At least I hope that they'll get rid of install scripts, that's such a low hanging fruit that really should've be done a decade ago.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#122

Post by 10000truths »

joeblubaugh wrote: post #51

There has been a lot of pain at my various jobs installing a safe global npm config on every developer machine, asking people not to disable it, checking it with mdm tools. A safer out-of-the-box configuration is long overdue.

What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#123

Post by eranation »

kelnos wrote: post #117
eranation wrote: post #64

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

The idea that 7 days is overkill is crazy to me. Unless you need a specific new feature, you should usually be fine with a dependency version that was released months ago when starting a new project. Ditto for doing regular dep upgrades. The only issue I see is responding to vulnerabilities, where you want to upgrade immediately. But I think in that case it's fine to require the developer to be explicit in the new ve…

I agree, but in most recent cases a 1 day cooldown would have been enough.

I added a “how to bypass if you have to patch a zero day CVE” section to depsguard for all supported package managers.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#124

Post by skydhash »

themafia wrote: post #112
skydhash wrote: post #110

Earlier quoted context omitted.

> Part of the point the article makes is that most other popular languages have a comprehensive standard library. Both the Browser and Node.js standard library are fairly extensive. I don't think there's much you can do with other language you can't do with Node.js. And as a lot of newer languages have demonstrated (like zig and hare), you don't need an extensive one.

It used to be true. The early days of node were pretty paltry. I think a lot of developers and projects have picked up these dependencies by habit and accretion and have never factored them out.

My pet peeve is when a developer picks up a library for just a few lines of code, and it turns that this library picks up another one that's not even relevant to its core domain. Whenever you get to the leaves of the dependency tree, it usually turns into a joke. Byte sized libraries everywhere.

Like you have axios.js that decides in turn to depends on the "follow-redirects" library. IMO, the best move would be for axios to vendor the code. Same with "proxy-from-env" Just tiny libraries scattered all over the web. Something like axios, should purely depends on the runtime library.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#125

Post by llbbdd »

bichiliad wrote: post #85
jollyllama wrote: post #20

Earlier quoted context omitted.

> It seems like it might just be that Python/npm are juicier targets? Attackers go where the victims are. Frontend is a monoculture with the vast majority using NPM; backend, less so. This isn't an excuse for NPM, but another strike against it. You could also argue that the attacks make a deeper point about frontend vs backend devs, but I won't go there.

Why would you even imply something like that?

They feel the need to compete given that jokes about "backend" devs write themselves

Re: 'No way to prevent this,' says only package manager where this regularly happens

#126

Post by dpark »

0xbadcafebee wrote: post #106
eranation wrote: post #64

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.

If there was a good reason to believe the pop tarts you buy might unexpectedly be contaminated with dioxins, waiting a week would be prudent.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#127

Post by SupLockDef »

brunoborges wrote: post #37
aselimov3 wrote: post #8

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted. Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal. One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even…

Also....

Maven doesn't have "preinstall, install, post install", or " build.rs" for rust, executing arbitrary code during the installation.

The code that's executing with Maven is in your pom.xml, not some hidden code from a transient dependency.

That alone is a major design flaw in both npm and cargo.

Java is boring, because it works. People don't like boring stuff. It's more exciting to play the Russian roulette on each install!

Re: 'No way to prevent this,' says only package manager where this regularly happens

#128

Post by mort96 »

nothinkjustai wrote: post #94
est31 wrote: post #41

Earlier quoted context omitted.

There is build.rs, proc macros are unsandboxed, and lastly you install the binary so that you can run it. Even if the build and install were fully sandboxed, the binary could still do malicious stuff if ran.

Yeah no shit, if you download malicious code from the internet and run it on your computer you will get pwned. No matter if it’s from a package manager a zip file or a submodule. However the current npm vulns used a post install script.

I maintain that NPM malware use postinstall scripts just because they exist and are convenient. Had NPM not had postinstall scripts, the malware would have used a different mechanism and been almost exactly as effective.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#129

Post by dns_snek »

TiddoLangerak wrote: post #121
brunoborges wrote: post #80

Earlier quoted context omitted.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

You're missing the biggest root cause though, and that significantly hinders how well this translates between languages: the Java community has settled on fewer but large monolithic dependencies, whereas the JavaScript community has settled on many but small composable dependencies (for good historical reasons, but that's a topic in and off itself). This directly influences how well e.g. version pinning works. In the…

> At least I hope that they'll get rid of install scripts, that's such a low hanging fruit that really should've be done a decade ago.

How will that help? It's just going to break things that legitimately require them.

Instead of being infected upon running "npm install", you'll just get infected upon running "npm run" instead. The former is slightly more reliable but fixing that is just kicking the can down the road. Maybe we'll have a few days before the payloads get rewritten.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#130

Post by jiggawatts »

kibwen wrote: post #109
jiggawatts wrote: post #31

Earlier quoted context omitted.

Generally, other package managers aren't great either. Notably, crates.io / cargo has some of the same issues as NPM and the verbiage of their excuses for not fixing these problems is oddly similar. Something fascinating about the design and architecture of programming languages and their surrounding ecosystems is the enormous leverage that they provide to the "core team": For every 1 core language developer[1]... ..…

You appear to have missed that NPM is owned by Microsoft. In addition, crates.io has not flatly refused to support namespaces, there's an entire accepted RFC for it: https://github.com/rust-lang/rfcs/pull/3243 At the same time, note that namespacing does nothing to prevent any sort of problem here. Namespacing is great for package organization and making provenance more deliberately obvious, but beyond that it's not…

> NPM is owned by Microsoft.

I did not miss that.

The "culture" of NPM was firmly established long before the acquisition by Microsoft.

Similarly, there clearly isn't the same feeling of "ownership" over NPM and its giant pile of anonymously published packages as there is over NuGet where a substantial fraction of the traffic is Microsoft customers downloading Microsoft packages for Microsoft DotNet development on Microsoft Visual Studio for Microsoft Windows Server.

Post reply on HN