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

Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

medium.com

Post reply on HN
Print view View original

101–110 of 412 posts

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#101

Post by croon »

Foxboron wrote: post #56
croon wrote: post #13

Earlier quoted context omitted.

But the broad issue will never be resolved. The entire foundation of society is built around some trust. What has proven to work is that we trust actors who are identifiable and have something to lose. This goes with everything from your bank, to government, to name brands, to your local restaurant. Nix package managers/repositories have a level of scrutiny to get into, and highly dedicated people in charge of. Rando…

>Nix package managers/repositories have a level of scrutiny to get into, and highly dedicated people in charge of. Random github repos (or npm packages) are extremely low effort/risk to set up. That's not really true though. Nix doesn't support signed sources, there are no signatures in the package repository and in theory "John Doe" with no information can add packages and send pull-requests. In practise nixpks is j…

Oh, I'll really show my ignorance here. You're right. I was interpreting Nix as *nix, and your average enterprise distro of linux.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#102

Post by brabel »

jeswin wrote: post #63
kasperni wrote: post #32

I'm surprised the reverse fully-qualified domain name (FQDN) model used by Java isn't more widely adopted. If you want to upload artifacts to the main repository (Maven Central) you first need to show ownership of a particular domain. For example, via a DNS TXT record (example [1]). Would make these kind of attacks a lot more difficult. [1] https://issues.sonatype.org/browse/OSSRH-61509

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

> Javas FQDN model is actually pretty bad in practice

Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#103

Post by Foxboron »

croon wrote: post #101
Foxboron wrote: post #56

Earlier quoted context omitted.

>Nix package managers/repositories have a level of scrutiny to get into, and highly dedicated people in charge of. Random github repos (or npm packages) are extremely low effort/risk to set up. That's not really true though. Nix doesn't support signed sources, there are no signatures in the package repository and in theory "John Doe" with no information can add packages and send pull-requests. In practise nixpks is j…

Oh, I'll really show my ignorance here. You're right. I was interpreting Nix as *nix, and your average enterprise distro of linux.

Yes, it's not really easy when people use these ambiguous names and talk about them in ambiguous ways.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#105

Post by dininski »

technics256 wrote: post #47

Can't there be a "package signature" of some sort that is specified and checked against in a package-lock.json or yarn.lock?

I'll try to answer this from a JS-specific perspective. As someone previously mentioned - you do get hash checks if you're using `npm ci` in your CI/CD setup. You get the resolution path as well. Which is all you need to reproducibly resolve dependencies, *if* you have set up npm correctly in your pipeline. It would be unlikely to be exposed to this particular attack, at least not automatically in your deployment pipelines.

However this is still very, very dangerous, because of day-to-day engineering, really. Any engineer doing a simple `npm install` can inadvertently bring in and execute malicious code from their machine. From there on out it would be somewhat trivial to gain further access to the same network the code war run from.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#106

Post by brabel »

XorNot wrote: post #73
Aissen wrote: post #58

Earlier quoted context omitted.

Or the URL-based model used by Go.

At this point I really wish we'd just go with a proper cryptography model, with a discovery overlay to provide names. What I want as a developer is to establish my trust relationship to developers of libraries I depend on. `npm install ` should first check a record of signing keys in my source code repo, then check a user-level record of signing keys I've trusted before, and then - and only then - add a tentative tru…

Maven Central has used PGP for adding "trust" to library authors since the 90's!

https://central.sonatype.org/pages/requirements.html#sign-fi...

If only people creating new package managers would bother to spend an hour or two learning prior art.

With npm, you can only add "trust" to npm itself LOL: https://docs.npmjs.com/about-pgp-signatures-for-packages-in-...

What a joke.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#109

Post by Triv888 »

jtsiskin wrote: post #9

That is insane that any company allowed this to happen. ""That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration," a Microsoft spokesperson said in the email." No, npm has scopes for a reason, why would that not fix this issue?

Automatic updates from poor sources is probably a bad idea anyways... whether they prioritize local packages or not. (I.E.: Play Store, PyPy, etc...)

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#110

Post by littlestymaar »

brabel wrote: post #102
jeswin wrote: post #63

Earlier quoted context omitted.

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

> Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.

> Right, that's why we see this kind of attack all the time on Maven Central, but never on npm...

Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems…

There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN…

[1] a quick ddg search, just last month https://securityboulevard.com/2021/01/sonatype-stops-softwar...

Post reply on HN