4 ms·
The Gitea one looks marginally interesting, but is probably not exploitable in practice (unless Gitea or whoever else isn’t properly isolating jobs on dedicated
by woodruffw 4mo ago
The Gitea one looks marginally interesting, but is probably not exploitable in practice (unless Gitea or whoever else isn’t properly isolating jobs on dedicated VMs). I suspect GitHub Actions has similar behavior and is not considered exploitable because the user is assumed to already have local, non-namespaced root access.
- Scaled 4mo agoGitea action runner has a bunch of different ways to setup and doing the isolation properly looks tricky. The documentation doesn't provide any isolation tests to administrators, either. The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users. Not flawless security, but it's something...
- woodruffw 4mo ago> The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users. This recommendation seems incompatible with third-party collaboration, at least on its face!
- dspillett 4mo agoPotentially, but for many projects things like that are tools that you want to control access to anyway. Anyone wanting to update the CI/CD process who isn't a trusted part of the project should be having their changes properly reviewed by someone who is anyway, at which point the reviewer is the trusted user not the random external entity.
- woodruffw 4mo agoI don’t disagree with that, but I think GitHub has shown that projects want to have their cake and eat it too. GitHub has also shown that it’s incredibly easy to design an insecure CI/CD that satisfies that goal, but I see that more as a symptom of them being first-to-market rather than an inherent quality of the problem.
- fluoridation 4mo agoWait, isn't this about protecting the machine running the actions? If someone hosts a project on Github and allows anyone to run actions, it's Github's problem if there's a vulnerability to exploit. It's their installations that are going to get compromised, not necessarily the project's data.
- m4rtink 4mo agoThe idea is you first review PRs from external contributors before allowing the CI to run on them.
- woodruffw 4mo agoI understand the idea. The point was that it isn't good enough: humans are fallible, so you still want to provide a secure CI/CD environment for untrusted external contributors.
- smsm42 4mo agoMany projects have CI setups that run code (Makefile can run any code, for example). Which means, an untrusted third-party contribution would allow that party to run arbitrary code on CI platform. Yes, the solution is to not let untrusted third-party code to be run without manual review.