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

141–150 of 412 posts

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

#141

Post by ex_amazon_sde »

Ex-Amazon SDE here.

> a unique design flaw of the open-source ecosystems

This is a big generalization.

Inside Amazon, as well as in various Linux distributions, you cannot do network traffic at build time and you can only use dependencies from OS packages.

Each library has its own package and the code and licensing is reviewed. The only open source distribution that I know to have similar strict requirements is Debian.

[I'm referring to the internal build system, not Amazon Linux]

[Disclaimer: things might have changed after I left the company]

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

#142

Post by marcus0x62 »

anchochilis wrote: post #138
golergka wrote: post #130

Earlier quoted context omitted.

Migrating from public NPM to a privately-hosted, your own mirror of NPM is not a very complicated process, and if you already have a CI pipeline in place, it can be implemented completely transparently to developers. But as many other things that an organisation has to change as it grows from a single-founder startup to a real company, it's something many people just forget to do until they face the consequences.

Mirrors are great for speed and protecting you from dependencies getting randomly deleted off the public repo, but I don't think they can protect from malicious packages. They'll just get pulled into the mirror. At my last gig (Java), developers reviewed all third-party libraries + dependencies and manually uploaded them to a private Ivy server. I don't think that could work in the Node ecosystem, where every module…

Right — the only way to really identify malicious packages is a line by line audit... All the way down the dependency chain. On top of that, does a typical org using these packages have developers who can conduct these audits and identify obvious back doors? What about less obvious bug doors?

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

#143

Post by syshum »

CaptArmchair wrote: post #132
syshum wrote: post #118

Earlier quoted context omitted.

>>There are a lot of expensive things you can outsource. Responsibility isn't among those. That is not true at all, the industry both Development and even more so in Operations has been outsourcing responsibility for a long time, they is why we have support contracts, SLA's and other very expensive services we pay many many times more than the cost of hardware for... To outsource responsibility... Network down -- Cal…

I disagree. A support contract allows you to hold a sub-contractor accountable. But that's the extent of what an SLA does. What it doesn't do is diminish your responsibility towards anyone who relies on the services you provide yourself. These are distinct things. Put more succinctly, if the network's down: that's still very much your problem. Especially if you over-promised 100% availability to the end users of your…

I guess this is where we need to define our anology

for a sysadmin the customer is "the employer" and they do not really have a contract with the sysadmin, rather the employer has contract with Cisco, or Nimble, etc. the sysadmin has "outsourced" his/her responsibility in that context.

For example instead of rolling your own storage device using linux, or freenas or something else, you buy an expensive 3rd party solution with expensive support contracts to outsource their responsibility. If it goes down "I have a support ticket open with vendor" instead of "I am attempting to merge the lastest kernel patch I have downloaded from github"

That is the source of the phrase "No one ever got fired for buying Cisco" or insert name of other large vendor. They do not get fired for it because they have outsourced their responsibility

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

#144

Post by WrtCdEvrydy »

ehnto wrote: post #117

Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny. I guess it's a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.

If you are using `npm i` instead of `npm ci`... you are also guilty of this.

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

#145

Post by angry_octet »

magicalhippo wrote: post #60
xurukefi wrote: post #51

I 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 was thinking the same thing. Surely PayPal's packages should be signed by a certificate only PayPal has, and they would want to verify that before using their packages?

If the signature reqt is attached to the package metadata, the new package just removed it. If it's part of their custom build system, what signs third party packages? Would it just sign the new one anyway, because how does it know which ones should have PayPal internal signing? Or are you proposing manual controls? shudder

Channels and priorities embedded in the package tools are a better approach, combined with something like Artifactory. Some channels might require packages are signed, and possibly monotonically versioned.

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

#146

Post by RGamma »

uncledave wrote: post #119
ehnto wrote: post #117

Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny. I guess it's a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.

Yes. The way we develop software quite frankly scares the shit out of me on a daily basis.

Well it's mostly held together by trust and (in the commercial case) warranty. That said there's so many potential entry points for malicious actors it's not even funny anymore (esp. in desktop computing)...

I try not to think about it too much and have faith in the powers that be

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

#147

Post by SamuelAdams »

TeMPOraL wrote: post #126
ehnto wrote: post #117

Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny. I guess it's a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.

> I can understand it in a development environment I can't. It's incredibly wasteful time and resource-wise, and ties your development process to third-party providers (and your ISP), which fall over often enough in practice. It's a good practice to have a local cache of all the third-party dependencies you use, available to both developers and CI infrastructure.

> It's a good practice to have a local cache of all the third-party dependencies you use, available to both developers and CI infrastructure.

We have that, it's called Java and .NET, but apparently solved problems aren't interesting anymore.

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

#148

Post by adolph »

I think JFrog and Azure won the prize for product placement on this one. When the article listed “Azure Artifactory” I wondered if Azure was “sherlocking” JFrog, but no, they have a partnership. Given the SolarWinds vector I expect more investment in tooling security.

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

#149

Post by monoideism »

wh33zle wrote: post #112
XorNot wrote: post #73

Earlier quoted context omitted.

At this point I really wish we'd just go with a proper cryptography model, with a discovery overlay to provide names. What I want as a developer is to establish my trust relationship to developers of libraries I depend on. `npm install ` should first check a record of signing keys in my source code repo, then check a user-level record of signing keys I've trusted before, and then - and only then - add a tentative tru…

You might be interested in `crev`: https://github.com/crev-dev

Despite being very interested in Rust, this is the first I've heard of crev. It's a very cool project.

That said, it's interesting to me that several people are trying to get the project to drop the Web of Trust, and focus on code reviews. I'm the exact opposite - the code reviews are an interesting, experimental approach, but I'm interested in the project because of the cryptographic Web of Trust. Any use of dev-originated code signing in a package ecosystem is great. For this reason, I'd love for this to get major pickup from Rust, and beyond.

Finally, I am a bit wary because the project is starting to look moribund. It's important for projects like these to know that the maintainer is in it for the long haul, even if there's initially very little adoption. When the project founder writes that they're in a "fight for survival", it makes me think they may abandon the project if it doesn't get significant adoption.

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

#150

Post by oauea »

littlestymaar wrote: post #110
brabel wrote: post #102

Earlier quoted context omitted.

> Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.

> Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems… There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN… [1] a quick ddg search, just last…

That issue isn't even remotely similar, it's just someone uploading new packages and some people choose to use those instead of the official ones, god knows why. It didn't get pulled in automatically for existing projects.

Also, it's cute how you think maven is used orders of magnitude less.

Sure, the build systems probably won't CONSTANTLY be redownloading all the modules like NPM does, instead they keep a cache, but come on.

Post reply on HN