5 ms·
(Opinions are my own) From the article [1]: Rationale: Code execution on a Googler machine doesn't directly lead to code execution in a production environment
by gravypod 4y ago
(Opinions are my own)
From the article [1]:
Rationale: Code execution on a Googler machine doesn't directly lead to code execution in a production environment. Googlers can download and run arbitrary code on their machines - we have some mitigations against that, but in general this is not a vulnerability; we are aware of and accepting that risk.
[1]: https://giraffesecurity.dev/posts/google-remote-code-execution/#fn:2 https://giraffesecurity.dev/posts/google-remote-code-executi...
- 13of40 4y agoSure, but you can pivot to various things. If you're running with the right set of privileges, you can disable branch policies and push unreviewed code changes into a repository, or you can exfiltrate code from a repo someone has cloned to their dev box, or hit the internal payroll site and make that employee's direct deposits go to your account.
- jeffbee 4y agoThe whole point of "zero trust" networking is that running on the employee's machine is not much better than running it on any other machine. You can no more easily push unapproved code to Google's repo from an engineer's workstation than you could from wherever you are sitting right now.
- freeone3000 4y ago…given a web browser that is logged in as a google developer, of course
- seanmcdirmid 4y agoThe web browser session must be authenticated. You can't just log on to your Googler machine and begin using the internal network with your browser. Gnubby must be satisfied.
- jeffbee 4y agoI mean it's likely that a process running as a user who is logged in interactively and fully authenticated and recently 2FA's could do something but that thing isn't going to be very spectacular. What would it do? Try to sneak a malicious change into another changelist? I am not saying this is completely useless but it would only be step 1 of many that are unlikely to all succeed and would need to be laser-targeted to the right engineer with the necessary code ownership.
- 13of40 4y agoIt's a perfect way for an APT to get a foothold in your environment. Imagine if you could check in a unit test that "downloads updates" from somewhere and executes them. Now you've got 30 devs on that floor running your arbitrary code without any paper trail. And since we (generalizing here, I know) have this culture of thinking test code is junk anyway, is anyone going to scrutinize it or just click "approve" and move onto the stuff they think is important?
- jeffbee 4y agoThat’s a good reason to execute your unit tests in an ephemeral environment without network access. All I am saying about the issues raised in the article is that some organizations start from the assumption that engineers will run arbitrary codes on their devices and the rest of their security story follows from that. It is not necessarily irrational. If you think that is crazy, it might be because you don’t understand the base assumptions.
- seanmcdirmid 4y agoUnit tests don’t run on dev machines normally, you need to do something special to make that happen (which I’ve never done myself). Also, they by default run without external network access.
- sesuximo 4y agoImo it’s a little more scary if you imagine this being exploited on many machines. You could push “approved” code
- yadaeno 4y agoThe main risk is read access to the monorepo.
- rippercushions 4y agoThanks to the zero trust model, access to that would require additional authentication.
- saagarjha 4y agoAuthentication which is generally freely given several times a day?