10 ms·

A supply chain attack on PyTorch

463 points by roblabla 3y ago

CoolCold 3y ago
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 pipelines setup - those guys are quite allergic to giving sudo/root access at all
- guappa 3y ago
  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.
davnn 3y ago
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?
- vicktorium 3y ago
  you have to consider that in the black market the rates would absorb the illegality of the action. while 5k is 'clean'
  - ZoomerCretin 3y ago
    Monero is always clean, too.
- wslh 3y ago
  No, that is in general the issue with security bounties. They attract mainly people who have enough time for trial and error and/or prior domain expertise and/or extremely smart in specific software. Nowadays cybersecurity is a vast field and it is not the same to be a white hat hacker specialized in Google Chrome issues than one in iOS. Not saying it cannot be the same person but the amount of time required to catch issues is long. I think supply chain attacks are not being taken very seriously. Think that people working, for example, in Python or JavaScript use pip or npm daily no matter if they work for a nuclear agency or your uncle's bar.
- mardifoufs 3y ago
  In an earlier article about the exploitation of GitHub actions in general (which this specific attack on pytorch is part of) they said: >So far, we’ve submitted over 20 bug bounty reports, raking in hundreds of thousands of dollars in bounties. So I think this is part of a chain of bounties? Though that can still be argued to be a bit too low for how powerful this exploit could be :)
  - nightpool 3y ago
    Those are from different organizations, I think. So 5k from pytorch only but more from other orgs
- 1B05H1N 3y ago
  Maybe 5k is the max payout for the bug class?
- deleted 3y ago
  [deleted]
- pvg 3y ago
  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.
  - withinboredom 3y ago
    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.
    - pvg 3y ago
      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.
      - withinboredom 3y ago
        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.
        pvg 3y ago
        Yes that is exactly the sort of thing that has zero non-bounty dollar value and next to no legal or brand risk.
        tptacek 3y ago
- sp332 3y ago
  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-appropriate-risk-management-katie-moussouris/ https://www.zdnet.com/article/relying-on-bug-bounties-not-ap...
vicktorium 3y ago
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
- richbell 3y ago
  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.)
  - lanstin 3y ago
    Make the corporate proxy use an allow list only. Even then you fall prey to official PyPi hacked packages, but at least then the cryptominers or discord cred stealers can’t phone home.
  - kjok 3y ago
    > 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.
- kkert 3y ago
  [dead]
- chuckadams 3y ago
  > C has this solved "Reflections on Trusting Trust" was a demonstration of this in the C ecosystem long before package managers were a thing.
- SethMLarson 3y ago
  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 :)
dontupvoteme 3y ago
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.
- Havoc 3y ago
  Boeing is a lot more into military tech than airbus
  - dralley 3y ago
    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.
  - mshockwave 3y ago
    compare to Boeing's volume? maybe, but Airbus is one of _Europe_'s largest defense contractors
    - robertlagrant 3y ago
      Well, it does have quite a lot of European state ownership. It would be very surprising if it didn't win a lot of European contracts.
  - shakow 3y ago
    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.
gray_-_wolf 3y ago
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?
- richbell 3y ago
  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-calls-journalist-who-found-security-flaw-a-hacker-threatens-to-sue/ https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal...
  - azeemba 3y ago
    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.
    - richbell 3y ago
      It depends. Sometimes companies only permit testing in specific test domains, other times they permit it as long as your activity is clearly identifiable (e.g., including a custom header in all request). It does seem like walking a precarious tight rope.
- richardwhiuk 3y ago
  Essentially, generally, no. Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.
  - Twirrim 3y ago
simonw 3y ago
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 time adding features to PyTorch. Instead, we found a typo in a markdown file and submitted a fix." I really don't like this aspect of GitHub that people who have submitted a typo fix gain additional privileges on the repo by default. That's something GitHub can fix: I think "this user gets to trigger PRs without approval in the future" should be an active button repo administrators need to click, maybe in the PR flow there could be "Approve this run" and "Approve this run and all future runs by user X" buttons.
- trevyn 3y ago
  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?
  - withinboredom 3y ago
    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.
    - ethbr1 3y ago
      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.
      - 3y ago
1B05H1N 3y ago
How should one detect this kind of stuff? Also reverse props to the meta bug bounty program manager for not understanding the finding initially. I know it's difficult managing a program but it's not an excuse to brush something like this off.
SethMLarson 3y ago
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! :)
- tlarkworthy 3y ago
  > 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.
  - SethMLarson 3y ago
    Isolation and ephemerality can still be accomplished using virtualization while providing the benefits of self-hosted resources.
- sroussey 3y ago
  I just wish python would isolate all the pip install stuff and put in the project folder like has been done with nodejs for years.
  - bloopernova 3y ago
    Python's virtualenv does something similar by keeping all files under one directory.
arcza 3y ago
[flagged]
- pnt12 3y ago
  Why?
  - arcza 3y ago
    [flagged]
zX41ZdbW 3y ago
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-vulnerability-in-cdnjs 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 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.
- zX41ZdbW 3y ago
  But I continue to find garbage in some of our CI scripts. Here is an example: https://github.com/ClickHouse/ClickHouse/pull/58794/files 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...
  - EE84M3i 3y ago
    I don't understand this PR. How is it an "attack"? It seems to just be pinning a package version, was the package compromised, or was this more a "vulnerability"?
    - korhojoa 3y ago
      If they're pulling from master instead of from a known version, it could be changed to be malicious, and the next time it is fetched, the malicious version would be used instead. It's a vulnerability.
      - 3y ago
29athrowaway 3y ago
[flagged]
Klasiaster 3y ago
With GARM (GitHub Actions Runner Manager) it's easy to manage ephemeral runners: https://github.com/cloudbase/garm https://github.com/cloudbase/garm One should also use workflow approvals for external contributors.
cjbprime 3y ago
> Thankfully, we exploited this vulnerability before the bad guys. How do you know?
rthkljlkrj 3y ago
[dead]
apesternikov 3y ago
shameless plug: there are ways to run custom sized runner without risks associated with self hosted runners. fasterci.com ephemeral runners is one of them.
deleted 3y ago
[deleted]
benreesman 3y ago
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.
crabbone 3y ago
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.

463 points by roblabla 3y ago

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 pipelines setup - those guys are quite allergic to giving sudo/root access at all

guappa 3y ago
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.

davnn 3y ago

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?

vicktorium 3y ago
you have to consider that in the black market the rates would absorb the illegality of the action. while 5k is 'clean'
- ZoomerCretin 3y ago
  Monero is always clean, too.
wslh 3y ago
No, that is in general the issue with security bounties. They attract mainly people who have enough time for trial and error and/or prior domain expertise and/or extremely smart in specific software. Nowadays cybersecurity is a vast field and it is not the same to be a white hat hacker specialized in Google Chrome issues than one in iOS. Not saying it cannot be the same person but the amount of time required to catch issues is long. I think supply chain attacks are not being taken very seriously. Think that people working, for example, in Python or JavaScript use pip or npm daily no matter if they work for a nuclear agency or your uncle's bar.
mardifoufs 3y ago
In an earlier article about the exploitation of GitHub actions in general (which this specific attack on pytorch is part of) they said: >So far, we’ve submitted over 20 bug bounty reports, raking in hundreds of thousands of dollars in bounties. So I think this is part of a chain of bounties? Though that can still be argued to be a bit too low for how powerful this exploit could be :)
- nightpool 3y ago
  Those are from different organizations, I think. So 5k from pytorch only but more from other orgs
1B05H1N 3y ago
Maybe 5k is the max payout for the bug class?
deleted 3y ago
[deleted]
pvg 3y ago
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.
- withinboredom 3y ago
  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.
  - pvg 3y ago
    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.
    - withinboredom 3y ago
      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.
      - pvg 3y ago
        Yes that is exactly the sort of thing that has zero non-bounty dollar value and next to no legal or brand risk.
      - tptacek 3y ago
sp332 3y ago
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-appropriate-risk-management-katie-moussouris/ https://www.zdnet.com/article/relying-on-bug-bounties-not-ap...

vicktorium 3y ago

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

richbell 3y ago
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.)
- lanstin 3y ago
  Make the corporate proxy use an allow list only. Even then you fall prey to official PyPi hacked packages, but at least then the cryptominers or discord cred stealers can’t phone home.
- kjok 3y ago
  > 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.
kkert 3y ago
[dead]
chuckadams 3y ago
> C has this solved "Reflections on Trusting Trust" was a demonstration of this in the C ecosystem long before package managers were a thing.
SethMLarson 3y ago
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 :)

dontupvoteme 3y ago

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.

Havoc 3y ago
Boeing is a lot more into military tech than airbus
- dralley 3y ago
  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.
- mshockwave 3y ago
  compare to Boeing's volume? maybe, but Airbus is one of _Europe_'s largest defense contractors
  - robertlagrant 3y ago
    Well, it does have quite a lot of European state ownership. It would be very surprising if it didn't win a lot of European contracts.
- shakow 3y ago
  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.

gray_-_wolf 3y ago

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?

richbell 3y ago
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-calls-journalist-who-found-security-flaw-a-hacker-threatens-to-sue/ https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal...
- azeemba 3y ago
  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.
  - richbell 3y ago
    It depends. Sometimes companies only permit testing in specific test domains, other times they permit it as long as your activity is clearly identifiable (e.g., including a custom header in all request). It does seem like walking a precarious tight rope.
richardwhiuk 3y ago
Essentially, generally, no. Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.
- Twirrim 3y ago

simonw 3y ago

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 time adding features to PyTorch. Instead, we found a typo in a markdown file and submitted a fix." I really don't like this aspect of GitHub that people who have submitted a typo fix gain additional privileges on the repo by default. That's something GitHub can fix: I think "this user gets to trigger PRs without approval in the future" should be an active button repo administrators need to click, maybe in the PR flow there could be "Approve this run" and "Approve this run and all future runs by user X" buttons.

trevyn 3y ago
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?
- withinboredom 3y ago
  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.
  - ethbr1 3y ago
    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.
    - 3y ago

1B05H1N 3y ago

How should one detect this kind of stuff? Also reverse props to the meta bug bounty program manager for not understanding the finding initially. I know it's difficult managing a program but it's not an excuse to brush something like this off.

SethMLarson 3y ago

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! :)

tlarkworthy 3y ago
> 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.
- SethMLarson 3y ago
  Isolation and ephemerality can still be accomplished using virtualization while providing the benefits of self-hosted resources.
sroussey 3y ago
I just wish python would isolate all the pip install stuff and put in the project folder like has been done with nodejs for years.
- bloopernova 3y ago
  Python's virtualenv does something similar by keeping all files under one directory.

arcza 3y ago

[flagged]

pnt12 3y ago
Why?
- arcza 3y ago
  [flagged]

zX41ZdbW 3y ago

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-vulnerability-in-cdnjs 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 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.

zX41ZdbW 3y ago
But I continue to find garbage in some of our CI scripts. Here is an example: https://github.com/ClickHouse/ClickHouse/pull/58794/files 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...
- EE84M3i 3y ago
  I don't understand this PR. How is it an "attack"? It seems to just be pinning a package version, was the package compromised, or was this more a "vulnerability"?
  - korhojoa 3y ago
    If they're pulling from master instead of from a known version, it could be changed to be malicious, and the next time it is fetched, the malicious version would be used instead. It's a vulnerability.
    - 3y ago

29athrowaway 3y ago

[flagged]

Klasiaster 3y ago

With GARM (GitHub Actions Runner Manager) it's easy to manage ephemeral runners: https://github.com/cloudbase/garm https://github.com/cloudbase/garm One should also use workflow approvals for external contributors.

cjbprime 3y ago

> Thankfully, we exploited this vulnerability before the bad guys. How do you know?

rthkljlkrj 3y ago

[dead]

apesternikov 3y ago

shameless plug: there are ways to run custom sized runner without risks associated with self hosted runners. fasterci.com ephemeral runners is one of them.

deleted 3y ago

[deleted]

benreesman 3y ago

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.

crabbone 3y ago

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.