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

111–120 of 412 posts

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

#111

Post by zaarn »

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.

Why would it be infinitely harder to obtain log5j.com compared to typosquatting on npm? .com domains aren't THAT expensive.

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

#112

Post by wh33zle »

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…

You might be interested in `crev`: https://github.com/crev-dev

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

#113

Post by donaldihunter »

brabel wrote: post #98
donaldihunter wrote: post #90

This was inevitable from the moment we let build systems and runtime systems fetch things automatically and unsupervised from public repos. This is the simplest and most blatant approach yet, but taking ownership of existing projects and adding malicious code is an ongoing problem. Even deleting a public project can have the effect of a DOS attack. When I first used maven, I was appalled by how hard it was to prevent…

Funny that you mention Maven, because Maven is not really vulnerable to this kind of attack simply because it requires a groupId in all dependencies, and to publish under a certain groupId you must prove control of the domain it refers to, which makes this attack nearly impossible (it's only possible if you use an internal groupId which is not controlled by you on Maven Central, AND an attacker could claim that group…

Back then it would have been maven 2 which supported version ranges in a similar way to OSGi manifests. But I really only mentioned maven as the first build tool I used which reached out to public repos uninvited and could break my builds as a consequence of that.

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

#114

Post by syjer »

littlestymaar wrote: post #110
brabel wrote: post #102

Earlier quoted context omitted.

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

You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice).

To be noted, it makes this kind of attack more difficult, but not impossibile.

Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.

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

#115

Post by hobofan »

CuriousNinja wrote: post #53
jl6 wrote: post #17

The real solution is to design and build software components that can be finished , so they can be ruthlessly vetted - rather than the endless churn of updates.

Not sure why parent is being down-voted as I believe this is an important point. In my opinion this would be applying the unix philosophy of having small tools that does one thing and does it well to code libraries.

Because as long as the underlying hardware and technology overall keeps progressing there isn't much practicality in "finishing" software.

Sure you could just "finish" Linux at 5.0 and then introduce e.g. io_uring via Linux-with-io_uring 1.0 instead of adding it to Linux 5.1. Same goes for all the libraries that add support for io_uring.

Yes, you could "finish" some software on the feature level, but you would still need to maintain it if you want to add support for new platforms, etc., or it will become obsolete sooner or later. In the case of still maintaining libraries, this would solve nothing in the context of this attack vector.

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

#116

Post by bayindirh »

brabel wrote: post #106
XorNot wrote: post #73

Earlier quoted context omitted.

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.

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

No, no... We should move fast and break things. We can implement this in a week because the old dinosaurs are too close minded to implement these things.

Today, the hardware is cheap and network is reliable. No need for any safeguards or security features.

/s

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

#117

Post by ehnto »

Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny.

I guess it's a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.

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

#118

Post by syshum »

CaptArmchair wrote: post #31
rachelbythebay wrote: post #4

I’m cackling at how great this is. This is what happens when you trust the internet forever and just scarf down any old thing at build time. Of course it’ll get exploited! That’s what evil people do.

There are a lot of expensive things you can outsource. Responsibility isn't among those. Free software / open source propels engineering as you can share and leverage the results of collective efforts. However, at no point did the concept come with inherent guarantees about concerns such as security. esr defined 19 points for "good" open source software development in his seminal essay "The Cathedral and the Bazaar".…

>>There are a lot of expensive things you can outsource. Responsibility isn't among those.

That is not true at all, the industry both Development and even more so in Operations has been outsourcing responsibility for a long time, they is why we have support contracts, SLA's and other very expensive services we pay many many times more than the cost of hardware for...

To outsource responsibility... Network down -- Call Cisco... Storage Down Call EMC or Nimble... etc

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

#119

Post by uncledave »

ehnto wrote: post #117

Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny. I guess it's a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.

Yes. The way we develop software quite frankly scares the shit out of me on a daily basis.

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

#120

Post by avereveard »

littlestymaar wrote: post #110
brabel wrote: post #102

Earlier quoted context omitted.

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

apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier.

npm design was so bad that you could at the beginning upload over an existing version of your package name and break dependencies retroactively even to people that pinned versions.

if you want to try some good old whataboutism, at least try to be in the same ballpark.

Post reply on HN