[flagged]
Why?
A supply chain attack on PyTorch
41–50 of 109 posts
Re: A supply chain attack on PyTorch
#42Earlier quoted context omitted.
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.
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.
Re: A supply chain attack on PyTorch
#43Earlier quoted context omitted.
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
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.
Re: A supply chain attack on PyTorch
#44Earlier quoted context omitted.
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.
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.
Re: A supply chain attack on PyTorch
#45The 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 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 then.
Re: A supply chain attack on PyTorch
#46very 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.)
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.
Re: A supply chain attack on PyTorch
#47With GARM (GitHub Actions Runner Manager) it's easy to manage ephemeral runners: https://github.com/cloudbase/garm
One should also use workflow approvals for external contributors.
Re: A supply chain attack on PyTorch
#48Earlier 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…
For the second point, PyPI's trusted publisher implementation does this very well: https://docs.pypi.org/trusted-publishers/
Re: A supply chain attack on PyTorch
#49Hm, from the reading, it seem he was pretty careful to not do any harm, but still, is this type of practical research actually legal?
Essentially, generally, no.
Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.
Re: A supply chain attack on PyTorch
#50> Thankfully, we exploited this vulnerability before the bad guys.
How do you know?