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

21–30 of 109 posts

Re: A supply chain attack on PyTorch

#21

Post by dralley »

Havoc wrote: post #11
dontupvoteme wrote: post #5

I know that it is zeitgeist exploiting to say this, but seeing Boeing listed and not Airbus really says something to me. Lockheed being listed makes me wonder if the FBI/CIA really will (further) step up on cybercrime, because you now have potential national security implications in a core supplier to multiple military branches.

Boeing is a lot more into military tech than airbus

That's not entirely true, Airbus is a participant in most European military aircraft projects. They participated in Eurofighter for example and are part of the FCAS program.

It's true to the extent that the US does a lot more and broader military procurement in general, so Boeing gets a smaller piece of a much bigger pie. Wheras Airbus is getting a piece of most European projects as a member of one consortium or another, it's just a smaller pie.

Re: A supply chain attack on PyTorch

#22

Post by withinboredom »

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?

Self-hosted runners is the way to go, IMHO. Especially if you have bare metal resources. I love how fast my builds are with 16 cores, and gobs of ram.

Re: A supply chain attack on PyTorch

#24

Post by chuckadams »

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

"Reflections on Trusting Trust" was a demonstration of this in the C ecosystem long before package managers were a thing.

Re: A supply chain attack on PyTorch

#25

Post by mshockwave »

Havoc wrote: post #11
dontupvoteme wrote: post #5

I know that it is zeitgeist exploiting to say this, but seeing Boeing listed and not Airbus really says something to me. Lockheed being listed makes me wonder if the FBI/CIA really will (further) step up on cybercrime, because you now have potential national security implications in a core supplier to multiple military branches.

Boeing is a lot more into military tech than airbus

compare to Boeing's volume? maybe, but Airbus is one of _Europe_'s largest defense contractors

Re: A supply chain attack on PyTorch

#26

Post by shakow »

Havoc wrote: post #11
dontupvoteme wrote: post #5

I know that it is zeitgeist exploiting to say this, but seeing Boeing listed and not Airbus really says something to me. Lockheed being listed makes me wonder if the FBI/CIA really will (further) step up on cybercrime, because you now have potential national security implications in a core supplier to multiple military branches.

Boeing is a lot more into military tech than airbus

Are they? Airbus has its hands in quite a few major military programs (Eurofighter, A-400M, Tigre, Super-Puma, ...), as well as in spatial programs, especially satellite intelligence.

Re: A supply chain attack on PyTorch

#27

Post by azeemba »

richbell wrote: post #10
gray_-_wolf wrote: post #8

Hm, from the reading, it seem he was pretty careful to not do any harm, but still, is this type of practical research actually legal?

It depends on the company. Many companies have bug bounty or vulnerability disclosure programs that explicitly guarantee safe harbor+protections for researchers. However, not all organizations are happy to be contacted about security issues. Sometimes doing the right thing can still result in (threats of) legal repercussions. https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal...

The bug bounties are usually pretty clear that you aren't allowed to make changes in the production systems. Here they made many changes - including changing the name of a release.

The bug bounties also prefer seeing a working attack instead of theoretical reports. So not sure how they could have tested their attack in this situation without making actual changes.

Re: A supply chain attack on PyTorch

#28

Post by withinboredom »

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.

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 additional value vs. selling it on the black market.

So, as you can hopefully see, it is a balancing act between all parties.

Re: A supply chain attack on PyTorch

#29

Post by SethMLarson »

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: read-all" should be your default when creating a new workflow. Prevents lateral movement via modifying workflow code.

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

Consumers:

* Use a lock file with pinned hashes, either --require-hashes or poetry/pipfile

* Review the diff of the file getting installed, not the GitHub source code. This will get easier when build provenance becomes a feature of PyPI.

* If your organization is large enough, consider mirroring PyPI with approved releases so the manual review effort can be amortized.

* More coming in this space for Python, like third-party attestations about malware, provenance, build reproducibility, etc. Stay tuned! :)

Re: A supply chain attack on PyTorch

#30

Post by sp332 »

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?

Bug bounties do not compete with the black market. Also on the business side, they are not as efficient as just paying an internal QA or security team. Katie Mousouris, who set up Microsoft's original bug bounty program has gone into a lot of detail on this. E.g. https://www.zdnet.com/article/relying-on-bug-bounties-not-ap...
Post reply on HN