Live data from Hacker News

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

medium.com

91–100 of 412 posts

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

#91
PGP signing of packages should be table stakes for publishing to a public repository. If unsigned packages are accepted by a public repository to reduce friction for newbies, such packages should be hidden by default.

Then, build tools should be configurable such that they only pull in dependencies signed by PGP keys drawn from a whitelist.

Finally, companies need to maintain private repositories of vetted dependencies and avoid pulling from public repositories by default — and this requirement needs to be configurable from the project's build spec and captured in version control.

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

#92
post #87
post #46

Earlier quoted context omitted.

Worse: you can’t even scope it to an org, and some integration points are only available to org owners! GitHub is terrible.

That explains why at a place I worked we had multiple github orgs for different subteams, and/or they were really cheap ... yeah confused now.

We also have multiple orgs, but we hit the requirement that you only have one bot account. It would be super nice if GitHub allowed much tighter scoping for PATs.

I don’t know how many GitHub orgs the Linux Foundation has, but... hundreds? Having one bit account with wide permissions is a non starter

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

#93

Earlier quoted context omitted.

I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, and npm itself is literally a tool for installing code to execute later , so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. This is really a complete n…

“install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.…

Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.

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

#94
post #66

Earlier quoted context omitted.

There are a lot of expensive things you can outsource. Responsibility isn't among those. Free software / open source propels engineering as you can share and leverage the results of collective efforts. However, at no point did the concept come with inherent guarantees about concerns such as security. esr defined 19 points for "good" open source software development in his seminal essay "The Cathedral and the Bazaar".…

Offtopic, but I found nowhere to actually ask this question. Does anybody know if ESR is still alive? His blog [1] has not been updated in months--and looking at his post dates, this seems really out of character--, he hasn't posted anything on twitter, or his usual channels. [1] http://esr.ibiblio.org/

This [0] is from Jan 2021.

[0]: https://lists.nongnu.org/archive/html/gpsd-dev/2021-01/msg00...

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

#95
post #14

To mitigate this kind of supply chain attacks for python, we have created following tool [1], that will check python packages on Artifactory instance you specify and create packages with the same name on the PyPi. [1] https://github.com/pan-net-security/artifactory-pypi-scanner

The thing that just happened is like a catastrophic chain-reaction collision in space. Now we will have to use guids for everything. Nothing has meaning.

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

#96
post #93

Earlier quoted context omitted.

“install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.…

Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.

> Eventually you containerize the container and realize that only a single if is enough for everyone.

You either have a typo somewhere or are not being very clear. Either way, keep editing.

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

#97
post #72
post #63

Earlier quoted context omitted.

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

I believe the TXT record validation is only an additional measure, eg to prevent a random developer from registering/uploading a package like org.apache.http2. Surely other authentication methods are used in practice. I find it hard to believe any high profile organization would allow their domains to expire, or else they would also lose e-mail and websites, right?

> I find it hard to believe any high profile organization would allow their domains to expire

Off the top of my head I remember both Microsoft (hotmail.co.uk) and Foursquare forgetting to renew their domains.

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

#98

This was inevitable from the moment we let build systems and runtime systems fetch things automatically and unsupervised from public repos. This is the simplest and most blatant approach yet, but taking ownership of existing projects and adding malicious code is an ongoing problem. Even deleting a public project can have the effect of a DOS attack. When I first used maven, I was appalled by how hard it was to prevent…

Funny that you mention Maven, because Maven is not really vulnerable to this kind of attack simply because it requires a groupId in all dependencies, and to publish under a certain groupId you must prove control of the domain it refers to, which makes this attack nearly impossible (it's only possible if you use an internal groupId which is not controlled by you on Maven Central, AND an attacker could claim that groupId successfully with Sonatype, AND you configure Maven to first look at Maven Central, and only then at your internal repos which would be stupid to do as you normally do the exact opposite - and most enterprise setups won't even proxy to Maven Central at all).

Also, Maven uses pinned versions, normally, and won't just download whatever newer minor version happens to be published when it builds, which again makes this attack quite hard to pull off.

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

#99
post #58

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

Or the URL-based model used by Go.

What does the url model bring?

Packages are typically considered immutable once published. If I have a particular package e.g. "FooLib.Bar v 1.2.3" then this zip file should _always_ contain the same bits. If I need to change those bits, e.g. to fix a bug then I need to ship e.g. "FooLib.Bar v 1.2.4"

Also packages aren't always small. So it makes sense to cache a copy locally. On dev machine "package cache" and in an org's "internal feed" and only check upstream if it's not there.

So I shouldn't need to go to the source url to get it. Ideally, I just ask "who has "FooLib.Bar v 1.2.3" for me?"

It also means that tampering can be detected with a hash.

But the "check upstream" model is now vulnerable to fake new versions.

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

#100
post #27
post #23

Earlier quoted context omitted.

I'm more amazed by the fact that they got bounties because the attack wouldn't be (easily) possible without insider knowledge on which dependencies their internal build system used

> To test this hypothesis, Birsan began hunting for names of private internal packages that he could find in manifest files on GitHub repositories or in CDNs of prominent companies but did not exist in a public open-source repository. If I'm not mistaken insider knowledge wasn't necessary.

my mistake
Post reply on HN