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

231–240 of 412 posts

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

#231

Post by ryukafalz »

ptx wrote: post #213
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…

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

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

#233

Post by nahuel0x »

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…

Giving fine-grained permissions to sandboxed libraries is the way forward, and probably a really good use case for WASM.

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

#234

Post by jonny_eh »

ryukafalz wrote: post #228
easton wrote: post #217

Earlier quoted context omitted.

I believe that Deno (the "successor" to Node being written by Ryan Dahl) is supposed to fix this for server-side JavaScript/TypeScript. It doesn't grant any permissions to anything unless you specifically give them out (so you can say that only a specific module gets access to the filesystem, for instance, and on top of that it can only access /srv and not /etc). https://deno.land/manual@v1.7.2/getting_started/permis…

This looks like it's... getting there, but still too coarse-grained. It looks like those permissions are granted to the whole Deno process? So if your program needed both access to sensitive data on the filesystem and network access, and it used a malicious dependency, that dependency could take advantage of those permissions and exfiltrate that data. I could be wrong, but I don't see any mention of permissions on im…

You're right. Deno only has app-level permissions. We need module level too.

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

#235

Post by detaro »

eecc wrote: post #224
detaro wrote: post #208

Earlier quoted context omitted.

Indeed, being able to apply capabilities on a package level would be great, but I don't know many languages/environments that implement this as a first-class feature.

Java does. Of course it’s never been used systematically and it has received precious little attention to DevOps ergonomics, but the infrastructure is there

I didn't know that. Do you happen to have a link with more details at hand?

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

#236

Post by siraben »

This attack demonstrates one of the problems outlined in the Nix thesis[0], that is the problem of nominal dependencies. That is, dependencies of the dependencies, build flags and so on are not taking into account, and in particular, the source of a package.

Nix makes it possible to query the entire build time and runtime dependency graph of a package, and because network access during build time is disabled, such a substitution attack would be harder to pull off.

The declarations for how the source is downloaded is specified declaratively and can be pinned to a specific commit of a specific Git repository, for instance.

[0] https://edolstra.github.io/pubs/phd-thesis.pdf

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

#237

Post by ryandrake »

Spooky23 wrote: post #193
Diggsey wrote: post #177

Earlier quoted context omitted.

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…

Coming from the embedded world, where a lot of projects are safety-critical, it always kind of shocks me to see how cavalier others in the software world are about bringing in third party dependencies. Need a bit of code that would take you a day to write? Naaah, just find a third party library that does it (and does god knows what else). And bam! Like that it's part of the build. No code review of the dependency. No security audit. No investigation of what other dependencies that dependency brings in. No investigation into license compatibility. Just slide it into the list of 200(!) other dependencies.

Maybe I'm a dinosaur, but I was taught a long time ago to use a dependency only if there was no other feasible alternative, and to thoroughly know every dependency you bring in as if it were your own code, and treat it as such. Because at the end of the day, you're shipping that code to the customer and stamping your name or your company's name on it. It's your reputation on the line, not the person behind the StudMaster69 GitHub account.

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

#238

Post by oauea »

littlestymaar wrote: post #156
avereveard wrote: post #120

Earlier quoted context omitted.

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.

Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java fo…

Sounds like you had some poor experiences with people who didn't know what they were doing.

The proper way to audit your dependencies is to run an in-house Maven repository server. Just like you would for npm, or any package repository really.

So you just spin up Sonatype Nexus, proxy the repositories you trust and disallow releases from being overwritten. That way you're certain the jar you're using today, is the exact same as the one you'll be using years from now.

Alternatively, if you have a vendor who ships their jars manually, you can just vet them, then upload them to your in-house Maven repository and have your developers pull them in as usual.

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

#239

Post by withinboredom »

nightpool wrote: post #33
withinboredom wrote: post #21

Earlier quoted context omitted.

Someone will eventually update deps, not necessarily CI. But now that devs machine is compromised. The attacker probably only has a small window of time after it gets in, but it should be long enough to exfiltrate dot-files and the source code of whatever it gets included in. Now they have ssh keys (mine are on a yubikey), and the GitHub url. They can further push malicious code into the repo.

I would hope most SSH keys are password-encrypted if not protected by a hardware token like yours, but I agree that the "unscoped-source" Gemfile syntax is a huge vulnerable hole, and a bad one. I'm just confused about how what seems like a pretty uncommon operation led to such an immediate response and code execution from Shopify. (I also don't think it's true that the attacker has a "small window of time"—as soon a…

It’s a small window because it’s going to take about 20-30 mins for the dev to figure out why tests failed, locate the bogus dependency and shut down their computer, notify secops, revoke keys (if they even think of that), etc.

If you know your computer was compromised. Shut down and reinstall from a backup, you don’t try and clean it.

Edit: I’m assuming the attacker would be replacing a dependency with an empty repo since they don’t know the actual source code. If they know the interface the dependency is supposed to provide, it could spread across the entire organization before anyone noticed.

> I would hope most SSH keys are password-encrypted

TBH, these are probably weak passwords for convenience.

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

#240

Post by umvi »

> I have been fascinated by the level of trust we put in a simple command like this one

sigh... am I the only one that likes environments where you can run simple commands to install stuff and you can generally trust your package managers? All the security folks love to act dumbfounded when people trust things, but post-trust environments have terrible UX in my experience. I hate 2FA, for example, because now I have to tote my phone around at all times in order to be able to access any of my accounts. If I lose my phone or my phone is stolen while travelling, I'm hosed until I can figure out how to get back in.

> So can this blind trust be exploited by malicious actors?

Yes, it can. Trust can always be exploited by malicious actors, and no amount of software can change that. And it creates a world that sucks over time. Show me a post-trust, highly secure environment that isn't a major PITA to use. And not just for computers. I'm sure you could use social engineering to abuse trust of customer service reps (or just people in general) and do bad things, and the end result will be a world where people are afraid do any favors for other people because of the risk of getting burned by a "malicious actor".

Post reply on HN