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

91–100 of 109 posts

Re: A supply chain attack on PyTorch

#91

Post by crohr »

jackwilsdon wrote: post #53
ethbr1 wrote: post #52

Earlier quoted context omitted.

What's the GitHub Actions tooling like for emphemeral self-hosted runners? Afaict, a huge portion of this attack came from persistence on the self-hosted runner. Absent that, they would have needed a container jailbreak as well, which substantially ups the difficulty. And if a repo is running <100 builds a day, spin up + kill container seems a small per-build price to pay for the additional security isolation.

GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it). https://docs.github…

I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public.

[1]: https://runs-on.com

Re: A supply chain attack on PyTorch

#92

Post by OJFord »

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…

They do care about this stuff though - a while ago I pointed out that `pr_closed` was run with the workflows from the PR(^); it was fixed promptly.

^So you could reject a PR that tries to add a bitcoin-mining workflow only to have it start bitcoin-mining on close. Or leaking secrets, releasing nonsense, etc. (I don't recall if non-/contributor status was also a factor. I think it was also ignoring that check.)

Re: A supply chain attack on PyTorch

#93

Post by trevyn »

LtWorf wrote: post #86
trevyn wrote: post #51

Earlier quoted context omitted.

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?

Pwn me.

Re: A supply chain attack on PyTorch

#94

Post by mike_hearn »

Twirrim wrote: post #70
richardwhiuk wrote: post #49

Earlier quoted context omitted.

Essentially, generally, no. Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.

I know Marcus, the guy they mention that first caught the problem. He had no end of trouble getting Meta to acknowledge the severity of what he'd found, and they just constantly went radio silence on him, in between not really understanding the problem. I ended up having to reach out to someone senior I knew in the security org there to get them to swoop in and pick up the report, before it got any actual traction (I…

One may suspect that they do know, but if you widen the scope of bug bounty programmes to encompass open source project supply chain then your programme immediately turns into a dollar piñata.

For a long time Apple didn't have a bug bounty programme at all. This wasn't because they didn't care about security. It's because their own internal audits were generating enough reports to saturate the available capacity for bug fixing, so paying for more reports would have just duplicated work. Generally this is the pattern at big tech firms: you want to turn your internal security teams to a problem for a while before starting to pay out for a new class of bugs. But of course it's hard to descope a problem from bug bounties, it looks very bad.

Re: A supply chain attack on PyTorch

#95

Post by trevyn »

Groxx wrote: post #79
KptMarchewa wrote: post #56

Earlier quoted context omitted.

GH actions are free on public repos.

Until someone tries to mine Bitcoin in yours, yeah

Do you have a case study?

My prior is that GitHub is pretty competent in understanding malicious PRs to open source repos, and wouldn’t penalize the repo owner without other evidence of wrongdoing.

Re: A supply chain attack on PyTorch

#96

Post by guappa »

SethMLarson wrote: post #31
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 sec…

Pinning… I wrote a library in python. The initial versions were to get it to work. Later I made the code much more efficient.

Of course 90% of the downloads come from the pinned old versions.

They were so inefficient… and are still contributing to create waste even though the new releases are like 20x faster.

Re: A supply chain attack on PyTorch

#97

Post by planede »

pvg wrote: post #20
davnn wrote: post #3

Is 5k an appropriate amount for such a finding? Sounds incredibly cheap for such a large organization. How much would something like this be worth on the black market?

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.

While I'm not familiar with the black market, I refuse to believe that an arbitrarily modified pytorch binary release has zero value.

Re: A supply chain attack on PyTorch

#98

Post by crabbone »

I would like to drive your attention to a different aspect that doesn't seem to get mentioned in this thread so far: more than 70 different Github workflows.

This is up to your eyeballs in proprietary Microsoft technology, and that is if you are the Colossus from the Attack on Titan kind of tall. And that is from an open-source project...

The article repeats this incantation: the project authors wouldn't have noticed this, the project authors would've never noticed that, we could allow ourselves to be sloppy because the authors aren't likely to oversee the whole thing...

This is just something else here that went wrong. It's the programming oneself so deep into the system you have very little control over, you don't have a good grasp of internal workings of... It shouldn't be surprising that such a system is easily compromised. It's not the specifics of how Github Actions operate that set PyTorch authors up for a failure, it's the choice to rely on proprietary tech, massively, without reservations.

Re: A supply chain attack on PyTorch

#99

Post by guappa »

CoolCold wrote: post #2

Among other nice things, I liked > We used our C2 repository to execute the pwd && ls && /home && ip a command on the runner labeled “jenkins-worker-rocm-amd-34”, confirming stable C2 and remote code execution. We also ran sudo -l to confirm we had root access. While it's not clear was it curated list of commands or just ALL, I assume the latter and that makes me feel no system administrator was involved into that pi…

Modern python development has become very similar to js… just install a few hundreds dependencies and hope for the best.

I'm personally sticking to distributions, and use pip just for testing. But I'm an outlier.

Re: A supply chain attack on PyTorch

#100

Post by kjok »

richbell wrote: post #12
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

You can't do much beyond setting up a corporate proxy that blocks or inspects outbound connections. Even then, you're relying on luck. These days it's practically a necessity for companies to shell out money to some sort of supply-chain protection software (Sonatype, Socket.dev etc.)

> These days it's practically a necessity for companies to shell out money to some sort of supply-chain protection software (Sonatype, Socket.dev etc.)

A number of some serious assumptions here. How can you be sure that you’re protected if you spend money on these commercial tools? It’s an arms race after all. There are other ways to protect yourself (pinning dependencies, allow list). A few open source tools are also available to audit code.

Post reply on HN