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

31–40 of 109 posts

Re: A supply chain attack on PyTorch

#31

Post by SethMLarson »

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

The recommended guidance is either vendoring dependencies or pinning to hashes (pip --require-hashes, poetry.lock, pipfile). When updating your dependencies you should review the actual file getting downloaded.

Compiled binaries are harder, you might consider compiling them from source and comparing the output. This is where build reproducibility comes in to play.

There's a lot more coming in the Python packaging security space that'll make this easier and just safer in general. Stay tuned :)

Re: A supply chain attack on PyTorch

#33

Post by pvg »

withinboredom wrote: post #28
pvg wrote: post #20

Earlier quoted context omitted.

This question comes of up frequently with these and it's premised on the hypothetical value of the bug on 'the black market'. The vast majority of such reported vulnerabilities have a 'black market' value of roughly zero, though, including this one. This doesn't say anything about the quality of the research, just that it's pretty hard to get monetary or other value out of most vulnerabilities.

It’s quite a bit more nuanced than that. Businesses only want to pay because it costs less than the damage done to the brand and/or lawsuits from users/data controllers. They don’t want to pay more than that. Researchers need money and are able to sell the fruits of their research to whomever they want. Generally, good-natured people will especially see if the bounty is worth it. It’s clean money, so it has additiona…

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.

Re: A supply chain attack on PyTorch

#34

Post by zX41ZdbW »

Recently, there were similar attempts (two) of supply chain attacks on the ClickHouse repository, but: - it didn't do anything because CI does not run without approval; - the user's account magically disappeared from GitHub with all pull requests within a day.

Also worth reading a similar example: https://blog.cloudflare.com/cloudflares-handling-of-an-rce-v...

Also, let me recommend our bug bounty program: https://github.com/ClickHouse/ClickHouse/issues/38986 It sounds easy - pick your favorite fuzzer, find a segfault (it should be easy because C++ isn't a memory-safe language), and get your paycheck.

Re: A supply chain attack on PyTorch

#35

Post by o11c »

trevyn wrote: post #18
simonw wrote: post #13

The key to this attack is: "The result of these settings is that, by default, any repository contributor can execute code on the self-hosted runner by submitting a malicious PR." Problem: you need to be a "contributor" to the repo for your PR to trigger workflows without someone approving them first. So: "We needed to be a contributor to the PyTorch repository to execute workflows, but we didn’t feel like spending ti…

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 daemon elsewhere, which could download straight from the CI in a verified way based on the CI's notion of the job name, it would be secure without privileges, but most CI systems don't want to preserve huge artifacts, and maintaining the separate daemon is also annoying.

Re: A supply chain attack on PyTorch

#37

Post by zX41ZdbW »

zX41ZdbW wrote: post #34

Recently, there were similar attempts (two) of supply chain attacks on the ClickHouse repository, but: - it didn't do anything because CI does not run without approval; - the user's account magically disappeared from GitHub with all pull requests within a day. Also worth reading a similar example: https://blog.cloudflare.com/cloudflares-handling-of-an-rce-v... Also, let me recommend our bug bounty program: https://gi…

But I continue to find garbage in some of our CI scripts.

Here is an example: https://github.com/ClickHouse/ClickHouse/pull/58794/files

The right way is to:

- always pin versions of all packages; - this includes OS package repositories, Docker repositories, as well as pip, npm, cargo, and others; - never download anything from the master/main or other branches; specify commit sha; - ideally, copy all Docker images to our own private registry; - ideally, calculate hashes after download and compare them with what was before; - frankly speaking, if CI runs air-gapped, it would be much better...

Re: A supply chain attack on PyTorch

#38

Post by BirAdam »

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

Well… sort of. C has become a standard with several implementations. It gains supply chain security by being decentralized. Likewise, it has many package managers with different repos for language specific things, and it then has many package managers and repos if we consider UNIX/Linux systems C development environments with dynamic linking and the like.

The issue is, for any given implementation, similar attacks could still happen, and the package repos are still probably vulnerable.

Re: A supply chain attack on PyTorch

#39

Post by tlarkworthy »

SethMLarson wrote: post #29

Great write-up! There's a few things you can do as either a producer or consumer to thwart this sort of attack: Producers: * Self-hosted infrastructure should not be running anonymous code. PRs should be reviewed before code executes on your infrastructure. Potentially should be a GitHub default when using self-hosted runners? * Permissions for workflows and tokens should be minimal and fine-grained. "permissions: re…

> Self-hosted infrastructure should be isolated and ephemeral, persistence was key for lateral movement with this attack.

Half the point of self hosting is to reuse cached resources.

Re: A supply chain attack on PyTorch

#40

Post by SethMLarson »

tlarkworthy wrote: post #39
SethMLarson wrote: post #29

Great write-up! There's a few things you can do as either a producer or consumer to thwart this sort of attack: Producers: * Self-hosted infrastructure should not be running anonymous code. PRs should be reviewed before code executes on your infrastructure. Potentially should be a GitHub default when using self-hosted runners? * Permissions for workflows and tokens should be minimal and fine-grained. "permissions: re…

> Self-hosted infrastructure should be isolated and ephemeral, persistence was key for lateral movement with this attack. Half the point of self hosting is to reuse cached resources.

Isolation and ephemerality can still be accomplished using virtualization while providing the benefits of self-hosted resources.
Post reply on HN