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

351–360 of 412 posts

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

#351

Post by linuxftw »

ryukafalz wrote: post #194

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…

I'm late to this conversation, but the thing that can restrict "doing anything" on your machine is SELinux.

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

#352

Post by HereBeBeasties »

andrejserafim wrote: post #20

Why would you want your CI to depend on an external source. Say a legit upgrade happened, but it has a breaking change. Now your build is broken. Fixed versions for as many things as you can (including OS images, apt packages, Docker images, etc) lead to changes in your CI under your control. Sure, you have to upgrade manually or by a script. But isn't plain build stability worth it? Not even talking about security.

It probably doesn't. But are you saying devs never updates their dependencies?

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

#353

Post by baybal2 »

HereBeBeasties wrote: post #344
baybal2 wrote: post #18

This is why end-developer signing is essential. This is not as amendable to CI, but that's the point.

How does it work in practice, though? For example, create-react-app in NPM has a bajillion deps. Do I trust 8,000 keys? Which ones are OK? I get that you could in principle namespace things (at least for package managers that support this) and insist on a small set of company-internal signing keys for those namespaces. But managing all that isn't easy and what about for package ecosystems that don't really have names…

> Do I trust 8,000 keys? Which ones are OK?

You can at least trust more 8000 developers whose keys are centrally signed, than 8000 packages thrown into signing CI tooling by who knows.

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

#354

Post by mike_hearn »

ryukafalz wrote: post #337
mike_hearn wrote: post #325

Earlier quoted context omitted.

They are not in tension. The Java security architecture is a mix of capability and module-level security. It's probably worth posting a quick refresher. The system is old but people don't use it much these days, and the documentation isn't that good. At one point I wrote a small JavaFX PDF viewer that sandboxed the PDF rendering code, to learn the system. I lost the source code apparently, but the hard part wasn't co…

> Sometimes you need to wrap a privileged operation to "dilute" it somehow. For example, imagine you have a module that allows arbitrary socket access. You also have an HTTP client. You would like the HTTP client to have network access, but for it to be usable by other modules that should only be able to contact specific hosts. Given what I've described so far that wouldn't work: the highly privileged code that can d…

That's the same thing I was just describing but recursed another level. It doesn't help by itself. Something needs to have permission to use the higher level of privilege - raw network access in my example, 'raw' http client access in yours. And something else needs to check that permission. Yes, you could wrap that privilege in a capability afterwards, but the reason Java has both capabilities and stack walking is because something needs to authenticate code and then authorise the production of a capability to start with.

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

#355

Post by HereBeBeasties »

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.

But this is exactly the philosophy in the NPM ecosystem where things like left-pad are rife. And NPM is generally considered a dumpster fire precisely because you need 8,000 deps for relatively "simple" projects like a basic create-react-app project.

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

#356

Post by austincheney »

Diggsey wrote: post #308
austincheney wrote: post #204

Earlier quoted context omitted.

Whether the package managers are poorly designed is completely ancillary. It really is primarily about developer laziness, incompetence, easiness. Proof: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ Sudden unplanned loss of availability is a catastrophic security problem, the A in the security CIA[1]. Worse is that the dependency that caused that problem was something that should never have been a depen…

How is that proof? You're again pointing to a design flaw in NPM: that authors can easily delete packages without warning. If you yank a package with cargo, it doesn't break people's builds who already depend on that package, it just makes it harder to add new dependencies on the package.

Blaming NPM for that problem is not a cure. Your users don’t care about the sad tired pleadings of a developer about some distant information system in the cloud. All the users care about is that your software was unavailable. That is a security failure.

Again, developers don’t care because they don’t own the consequences of such monumental failures, which is why they will happily and frequently repeat this deliberate mistake until they are terminated.

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

#357

Post by austincheney »

ritchiea wrote: post #278
GrinningFool wrote: post #268

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 won’t change until developers are terminated for gross negligence.

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

#358

Post by majormajor »

austincheney wrote: post #227
ritchiea wrote: post #212

Earlier quoted context omitted.

You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss about dependency management rather than use (flawed) industry standard tools and get to work on features. No one gets fired for using npm, you might get fired for insisting you build your own dependency management system because npm is insecure rather than working…

> No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.

Most devs would, however, end up owning the consequences of fully vetting their dependency tree when their manager gives them a terrible performance review for taking 20 times longer to do everything else than their peers.

This can't change bottom up. Even if you went the professional licensing route you'd need top-down regulation to force companies to only higher vetted and licensed professionals, and to actually do verification of projects to make sure all your best practices were being followed and following up on penalizing developers who weren't.

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

#359

Post by josephg »

Gehinnn wrote: post #332
josephg wrote: post #315

Earlier quoted context omitted.

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.

What about reviews and review certificates then? If you review a the package foo@1.0 you could publicly certify that it is not malicious and maybe earn some money with it. In turn, you back your claim with a financial security that you pay in case the package actually contains malicious code.

Thats a great idea - but in a centralized system like npm or cargo you don't need certificates to implement that. (Certs might be a nice implementation though.)

So yeah, there might be a "trusted security reviews with payments" shaped technical solution. I'd love to see someone flesh that out - that sounds like a potential solution to this problem (unlike developer-signed packages).

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

#360

Post by pabs3 »

beermonster wrote: post #214
ex3ndr wrote: post #161

Earlier quoted context omitted.

Does apt use tls by default today?

Apt supports TLS via apt-transport-https (as you are probably already aware) but I don't think it's default in either Debian nor (X)Ubuntu derivatives. I'd like to know why TBH. The packages themselves are signed though, so I guess the risk is now on server authenticity as opposed to package integrity.

The packages are not signed, but there is a hash chain from the signed Release files through to the packages themselves.
Post reply on HN