Live data from Hacker News

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

medium.com

311–320 of 412 posts

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

#311

Earlier quoted context omitted.

That's more for availability than security. Assuming you keep the crypto checksums / author signatures of all the source code and packages, you don't need to keep a copy of the source / packages. Just verify them at download time. Many Linux distros don't even have a copy of all those binaries, they rely on HTTP mirrors of random organizations. It's also useful for your organization to rebuild all of the source code…

One more advantage of keeping it together can be easier development cycle. IDE features like autocompletion and building would be faster if artifacts can be cached.

My Vim is indeed magic. I start typing in a name and it autocompletes, then adds includes for whatever the package the thing I just used is in. I also can't imagine going back to not having code search, with its turning every identifier into a link.

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

#312
post #10

I'm flabbergasted by how silly this is. Bump the version and the package manager chooses yours online vs. the private one. Amazing. How silly and how expensive is this going to be as this blatant security issue is going ripple on for the next months to come.

This is why explicit pins are a good idea. Whenever you finish a project you should set the explicit versions in the lock and then tag it. The problem is with dependencies of your dependencies, but if they are public, then by their nature they won’t be using private packages that can be hijacked.

Even public packages have been hijacked. Pin all your dependencies (transitive included) and then use automation (e.g. dependabot) to update the pinned versions as needed.

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

#313
post #179

https://security.googleblog.com/2021/02/know-prevent-fix-fra... At Google, we have those resources and go to extraordinary lengths to manage the open source packages we use—including keeping a private repo of all open source packages we use internally

That's more for availability than security. Assuming you keep the crypto checksums / author signatures of all the source code and packages, you don't need to keep a copy of the source / packages. Just verify them at download time. Many Linux distros don't even have a copy of all those binaries, they rely on HTTP mirrors of random organizations. It's also useful for your organization to rebuild all of the source code…

Google has a whitepaper on exactly how this works and the security aspects of the verifiable build system:

https://cloud.google.com/security/binary-authorization-for-b...

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

#314
This seems to be tending towards the generic problem of permissions that we have seen previously elsewhere.

For example in the case of Facebook, it used to be that users would accept permissions without considering them, and in-turn, various apps would access their data in bad faith.

Likewise for mobile apps.

Eventually Facebook removed many of the overtly powerful permissions entirely, likewise with the mobile operating systems.

In the case of mobile, the concept of "runtime permissions" was also introduced that required explicit approval to be granted at the time of authorization.

On Android, location access now prompts the user in the notification area informing the user of an app that accessed their location.

Can some of these ideas be borrowed to the package/dependency management world? "The package you are about to install requires access to your hard drive including the following folders: x/y/z/all?

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

#315
post #226

Earlier quoted context omitted.

I think this is critical. The actual runtime of any code needs to do way more than what it’s doing now. Simply relying on package signing and the like permits trusted but malicious actors. With Deno packages configured well it can really lock down and limit a ton of attack vectors.

>trusted but malicious actors I...think you might have bigger problems going on there. You're tryingto throw a tech solution at a problem that is fundamentally human in nature. That tends to leave nobody satisfied.

Tech solutions are the best solutions when they work! Fighting with your spouse over who does the dishes? Buy a dishwasher! Don’t want your ISP snooping on traffic? Use https / a VPN!

Unfortunately, package signing does nothing to protect against the threat vector presented here. The authentication system in npm is working fine. The problem is we put too much trust in software from the internet.

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

#316

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

It sounds like you are interested in a (distributed) capability-based security model. [1]

[1] https://enacademic.com/dic.nsf/enwiki/295618

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

#317

Earlier quoted context omitted.

Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to. It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to…

It's a practice that's so ingrained and so taken for granted that I suspect it will not change unless a big popular package gets hacked and the vulnerability effects a significant portion of apps written in a popular language like Javascript or Python. And I'm not really arguing against vetting your dependencies or improving dependency management. I'm just saying in the real world, that if I made this particular impe…

It might be ingrained these days, but this StackOverflow question asking for a package manager for C++ and not really getting any "obvious" answers is just under 10 years old: https://stackoverflow.com/q/7266097/1298153. Conan.io's first commit was in 2015.

You could also treat supply chain attacks on software dependencies like another IT security risk your company is exposed to (just like virus infection, ransomware attacks, phishing, etc) and go through the same thinking (and if appropriate other) processes to manage them. The company can then make a conscious decision on whether it's worth investing in mitigating, eliminating or accepting the risk.

There's lots of information out there on dealing with cyber security risks, e.g. https://www.ncsc.gov.uk/collection/risk-management-collectio....

(Apologies if this is all obvious, I'm just trying to highlight an alternative approach which might help you deal with the dilemma and not have to "solve" it all by yourself)

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

#318

Earlier quoted context omitted.

I'm not familiar enough with Java to have a strong opinion on this, but this HN comment from the linked article mentions that you can only have one SecurityManager per app, so sounds like that's still too coarse-grained: https://news.ycombinator.com/item?id=18599365

a security manager can examine the call stack and know which class from which package is asking to perform a privileged action within the app; the class object will tell you which loader loaded it, and you can ask the loader the physical location of where the class comes from if you want to be really sure no one has overloaded it.

Yes, it's a powerful and flexible mechanism. The problem is - how many people know (in detail) how to configure all of this power so as to take best advantage of it? My subjective perception is a that the answer is something like "a very small percentage of Java developers".

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

#319
post #213

Earlier quoted context omitted.

Could you solve this in Java using the SecurityManager stuff that was used to sandbox applets, or is all that considered broken these days? (I'm not sure if you can different SecurityManagers for different parts of the app though.)

I'm not familiar enough with Java to have a strong opinion on this, but this HN comment from the linked article mentions that you can only have one SecurityManager per app, so sounds like that's still too coarse-grained: https://news.ycombinator.com/item?id=18599365

Oracle’s own secure coding guidelines for Java [1] actually now recommend adopting a capability-based approach rather than relying on SecurityManager:

> FUNDAMENTALS-5: Minimise the number of permission checks Java is primarily an object-capability language. SecurityManager checks should be considered a last resort.

(Note: quite a lot of Java’s standard library is not designed along object-capability lines so you should take this advice with a pinch of salt).

[1]: https://www.oracle.com/java/technologies/javase/seccodeguide...

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

#320

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

It sounds like you are interested in a (distributed) capability-based security model. [1] [1] https://enacademic.com/dic.nsf/enwiki/295618

Yes, I didn't use the term explicitly in my comment but you're precisely right. ;)

Agoric (the company whose blog post I linked to) and the people behind it have done a ton of object capability work over the years.

Post reply on HN