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

221–230 of 230 posts

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

#221

Post by Hackbraten »

compel2160 wrote: post #200
Hackbraten wrote: post #186

Earlier quoted context omitted.

Except that exhaustively scanning for badness is provably impossible. It's inevitable that a false negative will slip through one day, and when that happens, it will compromise everyone who installs it, no matter if on day one or day eight.

The idea isn't to comprehensively make malicious code impossible - the idea is to make it difficult to sneak in. If the NSA wants to spend 500 billion$ to compromise an NPM package, there's very little we can do. But if waiting 3 days for security scans catch even 10% of malicious packages, that 's 10% fewer incidents everyone else has to deal with. And now people pwning maintainers must be much more sophisticated so…

Makes sense.

I just hope that the companies who currently perform security scans for free/for exposure have a sustainable business model. Once such a company gains reputation, there's diminishing returns in headlines currency.

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

#222

Post by cluckindan »

sidewndr46 wrote: post #192
cluckindan wrote: post #62

Earlier quoted context omitted.

What important functionality do you feel is missing from the commonly used JS environments (node and browser) that is causing people to install it as a third party dependency? The issue isn’t that the functionality doesn’t exist, it’s always backwards compatibility with versions where it did not yet exist.

How can one have a backwards compatibility issue if the solution didn't exist yet?

Polyfills/ponyfills for functionality that has been specified but not yet (widely) implemented, or just missing from some blessed runtime at hand.

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

#223

Post by panzi »

panzi wrote: post #203
SupLockDef wrote: post #127

Earlier quoted context omitted.

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…

How does Maven handle JNI? Is it also a build system for C/C++, or do packages with native bindings require manual build steps?

I googled a bit and found this snippet:

            
                exec-maven-plugin
                3.5.1
                org.codehaus.mojo
                
                    
                        Generate-shared-lib
                        package
                        
                            exec
                        
                        
                            bash
                            
                                generate-lib.sh
                            
                            
                                ${env.JAVA_HOME}
At least with certain plug-ins Maven will execute arbitrary commands at build time. And if you need that to build native bindings it feels like a big hole. Granted, most projects don't need JNI, I guess.

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

#224

Post by dns_snek »

throwaway27448 wrote: post #208
dns_snek wrote: post #153

Earlier quoted context omitted.

Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately. Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removi…

> Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time The "instead of" depends very much on the exploit and where it's wedged in the code. I doubt it's anywhere near 99%. Plus, getting the exploit to execute on the developer's machine is difficult to manage even in the best cases. > because everyone who thought that disabling…

> The "instead of" depends very much on the exploit and where it's wedged in the code. I doubt it's anywhere near 99%. Plus, getting the exploit to execute on the developer's machine is difficult to manage even in the best cases.

We don't need to guess, it's going to be wedged in index.js, probably on line 1.

Are you aware that all transitive dependencies are executed immediately? You depend on PackageA which imports PackageB, which imports PackageC, which imports a trojanized PackageD. As soon as PackageD is imported, it executes its payload and infects your machine.

All of this happens in a blink of an eye, as soon as you run anything that kicks off an import chain containing a trojanized dependency.

Try it for yourself. This will simulate a malicious transitive dependency: koa > cookies > keygrip > tsscmp. You don't need to do anything except import koa.

    mkdir demo && cd demo
    npm install --save koa@3.2.0
    echo 'import "koa";' > demo.mjs
    echo 'console.log("\n\n---  pwned by a transitive dependency ---")' >> node_modules/tsscmp/lib/index.js
    node demo.mjs
> Saying "well there are stupid people in the world" seems like a pretty bad justification to leave a hole open

Then you're calling much of the HN audience stupid. I've had this argument on here several times - and this is the top percentile of people who try to do something at all.

The justification for leaving this hole open is that it's a waste of time, resources, and mindshare patching a hole when there's a comparable and unpatchable hole right next to it. Advocate for things that actually work, like sandboxes.

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

#225

Post by exabrial »

Macha wrote: post #184
saghm wrote: post #71

Earlier quoted context omitted.

Probably the same reason that pretty much no other package manager (or even major email provider, when email is ostensibly the most famous use-case for it) has adopted it: the UX is atrocious.

Basically all Linux distro package managers?

All of maven central? Is that also significant enough (as well)?

NIH nihilism

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

#226

Post by eranation »

erikerikson wrote: post #218
eranation wrote: post #217

Earlier quoted context omitted.

I’m sure you mean well but I re-added it and kept it :) (It was re-added inline, right after the link. It says “I’m the maintainer”. I never re-removed it). I shouldn’t have removed it in the first place, and I re-added it right when someone called me out on it, and explained why I did it ( https://news.ycombinator.com/item?id=48156765 ). But again, it’s not like it’s hidden, it’s right in my bio. But let’s say I did…

Hrm, I'm very sorry. There it is, a little buried but I missed it, and it sucks that I falsely impugned your honor. The entirety of my criticism was based on my failure and I made it while you are helping fix things. FWIW, if anything, my invalid criticism was only a footnote to my comment. I was irritated by the article. It felt like a low blow on a dynamic that is a terrible, if minor, example of how small but impa…

I really appreciate your reply, and no apology needed! And all in all I am taking this as a lesson in:

- editing comments more transparently

- err on always disclosing vs not

Thanks again for the reply. <3

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

#227

Post by eranation »

shermantanktop wrote: post #162
eranation wrote: post #116

Earlier quoted context omitted.

More akin to letting astronauts stay in quarantine for a day in case they caught space bugs. If every other week I would notice the FDA recalls a popular brand that would have taken over my brain and transmit my bank password and SSN to a stranger, I might prefer drinking week old milk. Edit: not dismissing your analogy, it’s pretty much it.

If nobody drinks the milk until it’s a week old, that won’t help. I do think cooldowns help, it’s more that this analogy doesn’t help. The cow has to wake up and look at what milk she’s been putting out, and ideally the milk machine would use an early release channel so that some people will get the brain virus first.

Yeah, I mean, there are companies out there, that (for the goodness of heart or marketing or both, and I prefer if they did it for marketing because that would make it sustainable) who drink the milk as soon as it hits the shelf, and immediately tells the grocery chain to remote it.

tl;dr - there is financial interest for some companies to not have cooldowns and detect poisoned milk immediately.

More accurate analogy is a food tester for a king I guess, if your replace king with "everyone", (and the food tester did it for inbound traffic for his product and didn't risk their life for it)

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

#228

Post by joeblubaugh »

tkel wrote: post #55
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.

Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.

It’s hard to enforce on developer machines - there are lots of ways to install npm even if you never use it for managing development dependencies.

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

#229

Post by eranation »

youre-wrong3 wrote: post #137
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…

NPM doesn’t make it easy to do cooldowns because their apis prevent it.

What do you mean? it's a local config in your .npmrc (min-release-age=days or minimum-release-age=minutes for pnpm compatibility, although pnpm has 1 day by default if you have the latest...)

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

#230

Post by youre-wrong3 »

eranation wrote: post #229
youre-wrong3 wrote: post #137

Earlier quoted context omitted.

NPM doesn’t make it easy to do cooldowns because their apis prevent it.

What do you mean? it's a local config in your .npmrc (min-release-age=days or minimum-release-age=minutes for pnpm compatibility, although pnpm has 1 day by default if you have the latest...)

Because the npm api doesn’t list package ages individually. This is why ncu cooldown fails. The workarounds suck. NPM should fix their listings so this becomes super easy to solve.
Post reply on HN