Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
51–60 of 412 posts
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#52This is why end-developer signing is essential. This is not as amendable to CI, but that's the point.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#53The 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.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#54I’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.
You say this, but I feel like in the 20-odd years I’ve been using package managers I’ve seen very very few real world exploits?
Remember how much was temporarily broken in the leftPad event? Imagine if all that had been silently back-doored instead?
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#55I know that node has `package-lock.json` and `yarn.lock`, which include integrity checks. Are these checks decorative only? How could npm have been affected by this issue?
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#56Earlier quoted context omitted.
Helps in this specific case, but will not eliminate the broader issue. The broader issue is how can you trust 3rd party code to not do anything harmful, and it’s not like we can even perfectly trust our own fingers in that regard.
But the broad issue will never be resolved. The entire foundation of society is built around some trust. What has proven to work is that we trust actors who are identifiable and have something to lose. This goes with everything from your bank, to government, to name brands, to your local restaurant. Nix package managers/repositories have a level of scrutiny to get into, and highly dedicated people in charge of. Rando…
That's not really true though. Nix doesn't support signed sources, there are no signatures in the package repository and in theory "John Doe" with no information can add packages and send pull-requests.
In practise nixpks is just a well moderated user repository and the level of scrutiny is less then the enterprise distros can offer.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#57To 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
Uploading dummy packages to PyPi isn't the solution. It just pollutes PyPi and a nuisance to others. You have always been able to specify the `index-url` when installing packages using pip. This can also be added to `requirements.txt` files as well.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#58I'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
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#59I never understood why these package repositories don't include some (opt-in?) integrity checking option using digital signatures. If I download code that executes on my machine there should be at least the option to establish some level of trust. We have been doing that with linux distro package managers for decades. Seems like common sense to me.
I think the issue tends to be more that there's just so many packages (often nested 10+ deep) and it's best practice to keep them as up to date as possible.
When it's fairly typical for a JS project to have thousands of dependencies, there isn't really any practical way to both stay up to date and carefully review everything you pull in.
I think the only viable solution for companies taking this issue really seriously is to keep their numbers of dependencies down and avoid having significant deep/indirect dependencies.
Edit: as an example, in my company's Node stack (for 10 services) - there's >900 dependencies. In our React stack (for 2 sites), more than 1600.
Contrary to what you might think, these are actually pretty small, lightweight systems. So really whatever you might have thought was the worst-case scenario on numbers of deps, the reality is more like 10x that in the modern JS ecosystem.
In many ways, the vast number of tiny dependencies are one of the strongest points of the JS ecosystem. But it doesn't come without caveats.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#60I never understood why these package repositories don't include some (opt-in?) integrity checking option using digital signatures. If I download code that executes on my machine there should be at least the option to establish some level of trust. We have been doing that with linux distro package managers for decades. Seems like common sense to me.