Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A supply chain attack on PyTorch

johnstawinski.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: A supply chain attack on PyTorch

#81

Post by snnn »

o11c wrote: post #35
trevyn wrote: post #18

Earlier quoted context omitted.

The vast majority of repos should be able to run CI on pull requests with no privileges at all. GitHub can manage any resource utilization issues on their end. Is the issue here that a self-hosted runner was needed for some hardware tests?

The problem is that there are fundamentally 2 different kinds of builds, but the current tooling is weak: * pre-merge builds on PRs. These should not have privileges, but making the distinction between the two cases requires a lot of care. * official builds of "master" or a feature branch from the main repo. These "need" privileges to upload the resulting artifacts somewhere. Of course, if all it did was wake up some…

Ideally the builds for external PRs should not gain any access to any secret. But it is not practical. For example, you may want to use docker containers. Then you will need to download docker images from somewhere. For example, downloading ubuntu:20.04 from docker hub. That one requires a token, otherwise your request may get throttled. Even accessing most Github services requires a token. I agree with you that these things require a lot of care. In reality most dev teams are not willing to put enough time on securing their build system. That's why supply chain attacks are so common today.

Re: A supply chain attack on PyTorch

#82

Post by benreesman »

I’m only going to get into detail if anyone cares, but the actionable, germane thing is to be ready to move to torch-like tensor libraries.

The same design flaws in PyTorch that make it an interest attack vector (which in a very, very small way I had a part in, I also got this wrong) are the same design flaws that basically dictate that’s it’s more like an API than an implementation now: and those flaws are all the ways it’s too big to easily audit or port.

It’s a very good UI to accelerated computing, and I suspect it’s the “last one” for a long time.

I hope the next mainstream implementation will be TinyGrad, I fear it’ll be MLX, and I’d settle for JAX, but it won’t be PyTorch per se.

Re: A supply chain attack on PyTorch

#83

Post by tptacek »

withinboredom wrote: post #42
pvg wrote: post #33

Earlier quoted context omitted.

No, I don't think that holds much explanatory power - the vast majority of vulns have not only zero black market value, they also carry effectively zero brand or legal liability risk. This is also the case for this vuln.

Generally, getting root on internal infrastructure is just a step away from doing whatever you want. Even if it is just waiting for someone to ssh in with -A set so they can steal your ash keys.

A good rule of thumb is that if an exploit doesn't drop pin-compatibly into a pre-existing business model that has repeatedly used similar exploits in the past, it's worth nothing in a "commoditized" vulnerability market --- the kind HN tends to think of in these stories ("Zerodium" being the most common example). You can theoretically find someone who will listen to your story and give you money, but at that point you aren't so much selling a vulnerability as helping plan a heist.

I could be wrong about this, but I've been loud about it around people who do a lot of this stuff and none of them have dunked on me in public. :)

Re: A supply chain attack on PyTorch

#84

Post by LtWorf »

o11c wrote: post #35
trevyn wrote: post #18

Earlier quoted context omitted.

The vast majority of repos should be able to run CI on pull requests with no privileges at all. GitHub can manage any resource utilization issues on their end. Is the issue here that a self-hosted runner was needed for some hardware tests?

The problem is that there are fundamentally 2 different kinds of builds, but the current tooling is weak: * pre-merge builds on PRs. These should not have privileges, but making the distinction between the two cases requires a lot of care. * official builds of "master" or a feature branch from the main repo. These "need" privileges to upload the resulting artifacts somewhere. Of course, if all it did was wake up some…

> These "need" privileges to upload the resulting artifacts somewhere.

Only because pypi removed support for gpg and their only "signature" now basically is "was uploaded from a gh action".

Otherwise a maintainer could do it offline without needing to give microsoft total access to uploading to pypi.

Re: A supply chain attack on PyTorch

#85

Post by LtWorf »

akx wrote: post #48
o11c wrote: post #35

Earlier quoted context omitted.

The problem is that there are fundamentally 2 different kinds of builds, but the current tooling is weak: * pre-merge builds on PRs. These should not have privileges, but making the distinction between the two cases requires a lot of care. * official builds of "master" or a feature branch from the main repo. These "need" privileges to upload the resulting artifacts somewhere. Of course, if all it did was wake up some…

For the second point, PyPI's trusted publisher implementation does this very well: https://docs.pypi.org/trusted-publishers/

Isn't that what's causing the problem?

Without that there would be no need to have an action to do an upload. It could be comfortably and safely done offline.

Re: A supply chain attack on PyTorch

#86

Post by LtWorf »

trevyn wrote: post #51
o11c wrote: post #35

Earlier quoted context omitted.

The problem is that there are fundamentally 2 different kinds of builds, but the current tooling is weak: * pre-merge builds on PRs. These should not have privileges, but making the distinction between the two cases requires a lot of care. * official builds of "master" or a feature branch from the main repo. These "need" privileges to upload the resulting artifacts somewhere. Of course, if all it did was wake up some…

It’s called GitHub secrets. Builds off of main get the secrets, pull requests from randos don’t. And public repos don’t pay for CI on GitHub. Not rocket science, people.

> Not rocket science, people.

The smugness and overconfidence of someone who's about to be pwned?

Re: A supply chain attack on PyTorch

#87

Post by LtWorf »

mschuster91 wrote: post #74
adnanthekhan wrote: post #64

Earlier quoted context omitted.

Oh, you'll like this one then. Until 3 months ago GitHub's Runner images was pulling a package directly from Aliyun's CDN. This was executed during image testing (version check). So anyone with the ability to modify Aliyun's CDN in China could have carried out a pretty nasty attack. https://github.com/actions/runner-images/commit/6a9890362738... Now it's just anyone with write access to Aliyun's repository. :) (p.s.…

Whoa, there's a lot of stuff in there [1] that gets installed straight from vendors, without pinning content checksums to a value known-good to Github . I get it, they want to have the latest versions instead of depending on how long Ubuntu (or, worse, Debian) package maintainers take to package stuff into their mainline repositories... but creating this attack surface is nuts. Imagine being able to compromise just o…

> on how long Ubuntu (or, worse, Debian) package maintainers take to package stuff into their mainline repositories...

Really a misinformed comment.

For starters Ubuntu is for the most part a snapshot of Debian sid, so except for a few cases it will not have more modern versions.

The python packaging team is really hard working… In most cases stuff that doesn't get updated immediately is because it breaks something or depends on something new that isn't packaged yet.

Please stop demeaning the work of others when you seem to not know that it even happens at all.

Re: A supply chain attack on PyTorch

#88

Post by guappa »

Groxx wrote: post #45
trevyn wrote: post #18

Earlier quoted context omitted.

The vast majority of repos should be able to run CI on pull requests with no privileges at all. GitHub can manage any resource utilization issues on their end. Is the issue here that a self-hosted runner was needed for some hardware tests?

> The vast majority of repos should be able to run CI on pull requests with no privileges at all When there are no side effects and no in-container secrets and the hosting is free or reasonably limited to prevent abusers, ideally yes. Outside that, heck no, that'd be crazy. You're allowing randos to run arbitrary code on your budget. Locking it down until it's reviewed is like step 1, they can validate locally until…

They are so difficult. I wanted to stop random people to run code on my repository… I don't have any secrets or write access or anything to exploit. Just to avoid burning quota.

The issue is that now the pull requests don't get tested at all. I have to manually, locally, get all the commits, make a branch on the main repository with them, and then the actions run.

Re: A supply chain attack on PyTorch

#89

Post by guappa »

vicktorium wrote: post #4

very interesting i wonder about the over-dependence on third party packages and modules imagine the author of 'is-odd' injects a trojan there what are you gonna do? C has this solved but 'vendoring' is not as fast as this approach

> C has this solved

It hasn't… but C developers are much more careful about adding a dependency than js/python/rust/go developers. Mostly because adding a dependency in C is more annoying. In those languages it's just about adding one line.

Of course if you use a distribution and it's a famous library, it's to add a line as well. But then there is the filter of the distribution. Which would work for any language, but most developers vendor everything instead.

Re: A supply chain attack on PyTorch

#90

Post by Groxx »

guappa wrote: post #88
Groxx wrote: post #45

Earlier quoted context omitted.

> The vast majority of repos should be able to run CI on pull requests with no privileges at all When there are no side effects and no in-container secrets and the hosting is free or reasonably limited to prevent abusers, ideally yes. Outside that, heck no, that'd be crazy. You're allowing randos to run arbitrary code on your budget. Locking it down until it's reviewed is like step 1, they can validate locally until…

They are so difficult. I wanted to stop random people to run code on my repository… I don't have any secrets or write access or anything to exploit. Just to avoid burning quota. The issue is that now the pull requests don't get tested at all. I have to manually, locally, get all the commits, make a branch on the main repository with them, and then the actions run.

That just plain sounds Bad™, yeah. In the buildkite setup I interact with, I can at least just hit the "continue" button on the paused pipeline, regardless of any other GitHub state... which feels like table stakes to me.
Post reply on HN