Hacker News Reader

Comment by gravypod | Hacker News Reader

(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-executi...

View on HN

Sure, 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.

The 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.

…given a web browser that is logged in as a google developer, of course

The 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.

I 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.

It'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?

That’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.

Unit 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.

Imo it’s a little more scary if you imagine this being exploited on many machines. You could push “approved” code

The main risk is read access to the monorepo.

Thanks to the zero trust model, access to that would require additional authentication.

Authentication which is generally freely given several times a day?

Reply on news.ycombinator.com