Hacker News Reader

Comment by codezero | Hacker News Reader

I don't know if I missed it in the article, but did they say anything explicit about write access? Seeing the source may give access to new zero days, but it would be much worse if the attackers were able to seed a large number of commits into the code that introduce subtle vulnerabilities.

View on HN

Sounds like the attackers did not have write access. From the original blog post:

> The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.

I would also hope that direct commits don’t go immediately to a production system without some sort of review. At my workplace we have branch protections for all “main” branches that would result in a deployment. At least one other person has to review changes and all of our automated checks have to pass before anything can even get close to running through a deployment pipeline.

Whew, that's good to hear. I assume anyone trying to inject malicious code is going to try to do so in a way that doesn't go through normal code review channels.

True. However, hopefully that’s being mitigated through things like not allowing authors to review their own commits, not using the same accounts to push code changes and do deployments (i.e. having a read-only account for deployments), etc.

However, if it were an admin account that were breached that would definitely make it possible to circumvent any number of protections in place.

At least for the projects I work with at Microsoft, nearly no user accounts have direct write access to source repos. Checkins are done by a service account only after a pull request has successfully been built and run tests, and has been signed off on by appropriate users -- e.g. I can't sign off on my own PR.

EDIT: Sorry, somehow I missed the reply by thatsamonad or I would have replied to it instead of its parent.

I meam it sounds like a good security mesuare but also like a pain to work with? I have recurring nightmare that management realize that submits can be blocked if they generate CI warnings and there will be no warnings anymore.

Tools that generate warnings can be configured to only do so on new or modified code. We do the same for our code. It can be a difficult, but ultimately some codebases require it.

This reminds me of The Linux Backdoor Attempt of 2003[0], when someone (maybe a three-letter agency, maybe not) was able to insert a subtle bug in the Linux kernel.

[0]: https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

> was able to insert a subtle bug in the Linux kernel.

... was able to insert a bug into a mirror of the kernel, which was caught in short order.

... which was caught in short order

That means nothing, of course it was caught, otherwise we'd never had heard about it. We can only speculate about the ones that haven't been caught...

We can look at why it was caught (people paying attention to commits, policy of requiring commits to be properly signed off), and conclude that it would be difficult to add anything without being caught. Or, put differently, if you believe that bad actors can get around that level of precautions, you might as well give up because everything else would be equally compromised.

I thought BitKeeper was the main repo and CVS was the mirror?

Yeah, from that link:

> But some people didn’t like BitKeeper, so a second copy of the source code was kept so that developers could get the code via another code system called CVS. The CVS copy of the code was a direct clone of the primary BitKeeper copy.

Reply on news.ycombinator.com