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

191–200 of 412 posts

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

#191

Post by specialp »

Diggsey wrote: post #177
Communitivity wrote: post #158

This doesn't surprise me. Horrify.. yes. I've noticed more dev teams succumbing to the temptation of easiness that many modern package managers provide (NPM, Cargo, Ivy, etc.) - especially as someone who has to work with offline systems on a regular basis. Because of that ease there are fewer tools and tutorials out there to support offline package management. There are more for using caches, though these are often a…

I disagree: the problem is not that package managers make things easy, it's just that several of them are poorly designed. The fact that pip/npm/gem etc. look for packages in a fallback location if not found in the private repository is a terrible design flaw. One which not all package managers have. For example, when you add a cargo dependency from a private registry, you have to specify the registry that the depend…

In the case of RubyGems for some time now it has been throwing a warning if you do not use the `source` block to scope for gems coming from multiple gemservers.

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

#192

Post by ehnto »

WrtCdEvrydy wrote: post #144
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.

If you are using `npm i` instead of `npm ci`... you are also guilty of this.

The secret is to not use NPM at all. It's the worst offender for exploding dependency trees.

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

#193

Post by Spooky23 »

Diggsey wrote: post #177
Communitivity wrote: post #158

This doesn't surprise me. Horrify.. yes. I've noticed more dev teams succumbing to the temptation of easiness that many modern package managers provide (NPM, Cargo, Ivy, etc.) - especially as someone who has to work with offline systems on a regular basis. Because of that ease there are fewer tools and tutorials out there to support offline package management. There are more for using caches, though these are often a…

I disagree: the problem is not that package managers make things easy, it's just that several of them are poorly designed. The fact that pip/npm/gem etc. look for packages in a fallback location if not found in the private repository is a terrible design flaw. One which not all package managers have. For example, when you add a cargo dependency from a private registry, you have to specify the registry that the depend…

It's a little bit of both. Maybe "problem" is the wrong word. It's a risk that you need to understand and account for. If you're running a bank, it's an existential impact that you must avoid. If you're running a message board, it's not.

Look at what happened when the "left-pad" function disappeared from npm a few years ago. IIRC, it broke react. The downside of package managers like this is that many people have no idea what they are using.

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

#194

Post by ryukafalz »

I see a lot of people saying things like "this is why package signing is important" and "we need to know who the developers are" and "we need to audit everything." Some of that is true to some degree, but let me ask you this: why do we consider it acceptable that code you install through a package manager implicitly gets to do anything to your system that you can do? That seems silly! Surely we can do better than that?

This article from Agoric is extremely relevant here, from a previous such incident (re: the event-stream package on npm): https://medium.com/agoric/pola-would-have-prevented-the-even...

Put simply: in many cases, the dependencies you install don't need nearly as much authority as we give them right now. Maybe some of these packages need network access (I see a few named "logger" which might be shipping logs remotely) but do they need unrestricted filesystem access? Probably not! (They don't necessarily even need unrestricted network access either; what they're communicating with is likely pretty well-known.)

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

#195

Post by fortran77 »

I don't use npm much, but once I'm out of the initial development phase with any package manager and am "feature complete" we generally lock versions down so at least we're always pulling a specific version in.

And, of course, on production build machines, all packages are local.

This isn't just for "security" -- it's to ensure we can always build the same bits we shipped, and to avoid any surprises when something has a legitimate update that breaks something else.

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

#196

Post by [deleted] »

tarruda wrote: post #45
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

It seems some of the new package systems such as node/npm fail to learn from years of maturity of existing ecosystem such as Java's

[deleted]

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

#199

Post by throw_m239339 »

jrochkind1 wrote: post #184
mstipetic wrote: post #176

Earlier quoted context omitted.

It drives me crazy that "official" sounding package names like yaml are seemingly given basically first-come first serve, with no oversight. Publish anything you want, but call it Mark's awesome yaml library, or companyName-yaml or something like that so that people are aware that's not an officially supported project

What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time?

> What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time?

Just use name spaces. foo.com/yaml instead of yaml. NPM way of doing things is/was just insane, with no regard for trust or security. No wonder NPM corp then went into the business of selling namespaces, AKA selling trust...

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

#200

Post by iam-TJ »

beermonster wrote: post #172
nstart wrote: post #44

This post seems like a good time to note that by default, there's no direct way to verify that what you are downloading from dockerhub is the exact same thing that exists on dockerhub [1]. Discovered after seeing a comment on HN about a bill of materials for software, i.e., a list of "approved hashes" to ensure one can audit exactly what software is being installed, which in turn led me to this issue. [1] - https://g…

I think image signing support (or at least was) is not as good as it can be. It would be nice if more images were signed by publishers and verification performed by default. Even then, that only gives you a stronger indication that the image hasn't been altered since it was signed by the image author at any point after it being signed. However it is not a guarantee that the source produced the binary content. It's al…

Approximately 25,000 of just over 30,000 source packages are now reproducible builds - generating over 80,000 binary packages. See the graphic on the page you linked to:

https://tests.reproducible-builds.org/debian/unstable/amd64/...

Post reply on HN