Live data from Hacker News

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

medium.com

271–280 of 412 posts

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

#271

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.

Honestly, it’s one of the things that makes me nervous about running Linux on all of my computers. At least with Windows (and probably OSX), my updates come from a single vendor who has strict internal code audits and security requirements. With Linux (I’m using Pop), my updates come from a package manager with a crapload of packages, each maintained by a different team / group with no central policy. There’s no way the small team at Pop can review and audit all of the things in the apt package system, and there have to be plenty of maintainers of popular packages who get sweet offers to sell out.

Anyway. I’m sticking with Pop / Linux. But it does make me nervous!

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

#272

Earlier quoted context omitted.

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?

Unless it's a part of the standard library included with the language, nobody gets it. There has to be some designation before the name. It's not only node, python also does things like that

I don't understand how a designation in front of the name solves anything. The designation is basically just a name itself, you've just made it a two-part name, and a requirement that all names have two parts. ok, so?

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

#273
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

But Google is more or less an exception in this regard, from hiring their own offensive penetration testing teams to having a lot of paranoia in general about anything from outside. They had adopted a lot of good practices early on. Even most big companies are not as thorough as them. I wonder how they built this culture and if it is even realistic for smaller companies to aim for it.

At a previous job I pushed hard for this in a project I was responsible for, despite initial buy-in as time went on there was a consistent level of pushback about relaxing this requirement and allowing just importing anything ( the architecture of this was basically a separate repo storing ALL the dependencies where only a couple of people had commit access and where new dependencies were allowed after vetting )

Fortunately there was a hard legal requirement to vet every dependency license, otherwise I am not sure I would have been able to keep this workflow. As other posts say you do need a very strong commitment at the management level for this to work, besides security (where it feels that often it matters only until it costs money or until it’s even slightly inconvenient) it might be helpful to make a legal case (what if we ship something with a nested dependency on AGPL ) to get some help to establish these procedures.

I have been writing and architecting security related software for pretty much all my career and I find it quite scary how these days so much software delegates so much control to unvetted external dependencies.

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

#274

Earlier quoted context omitted.

OK, so again not Mavens fault but an utterly insane bureaucracy? Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?

I agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working o…

50 hours pr top level dependency not once or twice or ten times but every time does however sound like something "cache-like" is missing on the human level?

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

#275
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

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.

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

#277

Earlier quoted context omitted.

Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?

You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar. It was a common d…

That bureaucracy makes sense to me. You're _shipping_ those dependencies. When something misbehaves or allows an exploit it doesn't matter if it happened in a dependency or not -- the dependency isn't the one who's accountable to customers and the regulatory authorities.

It sounds like the processes in use to do this may have been pretty crappy in the organizations you've been with, but it also sounds like it would take less time than implementing a dependency's functionality from scratch in most cases you'd want to pull in a dep.

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

#278

Earlier quoted context omitted.

Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.

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 imperfection in software development practices my hill to die on at work, there's a 99% chance it is not good for me or my career. So my options are, swim with the tide knowing we're doing things imperfectly, or fight an uphill battle for a more perfect world knowing that unless we avoid some major vulnerability every other Javascript developer falls victim to, there will be many eyes in my office staring over at me wondering if my extra caution is really worth the company's investment. If I keep my job at all.

I want to write great software, but to do that, I need to actually have a job writing software. And until I get a job at Google or Facebook or Amazon (none of those being places I've ever actually applied to) I am generally working in conditions without the resources to do the kind of dependency vetting we're talking about in this thread.

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

#279

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.

Honestly, it’s one of the things that makes me nervous about running Linux on all of my computers. At least with Windows (and probably OSX), my updates come from a single vendor who has strict internal code audits and security requirements. With Linux (I’m using Pop), my updates come from a package manager with a crapload of packages, each maintained by a different team / group with no central policy. There’s no way…

For Linux, it's about choosing a distro you can trust. Most manage their own repos, some more carefully than others.

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

#280
post #270

Earlier quoted context omitted.

This is not correct. Installing packages only from a trusted (and signed) source protects against typosquatting, misread or confusing package names and many other risks.

forgive my naivety, but my understanding of the NPM and rubygems ecosystem is open source packages host their source code on github/gitlab. The source code is super easy to view. Often times, the author will use tags or branches dedicated to specific versions of the code. For distribution, js and ruby use rubygems and npm to host packages. If a developer wants to verify that the package hosted on npm is the same code…

I'm not sure what point you are making.

Yet, reviewing hundreds of thousands SLOCs (across different languages) and also checking legal compliance requires significant skills, time and efforts.

As an individual, you cannot justify reviewing the entire dependency tree across all your projects.

Thankfully you can rely on the packages reviewed and built internally by your colleagues - or use a Linux distribution that does thorough vetting.

Post reply on HN