5 ms·

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 wo

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.

thatsamonad 6y ago
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.
- codezero 6y ago
  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.
  - thatsamonad 6y ago
    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.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
CurtHagenlocher 6y ago
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.
- rightbyte 6y ago
  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.
  - tikkabhuna 6y ago
    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.
1f60c 6y ago
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-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...
- yjftsjthsd-h 6y ago
  > 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.
  - joosters 6y ago
    ... 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...
    - yjftsjthsd-h 6y ago
      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.
  - 1f60c 6y ago
    I thought BitKeeper was the main repo and CVS was the mirror?
    - yjftsjthsd-h 6y ago
      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.

thatsamonad 6y ago

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.

codezero 6y ago
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.
- thatsamonad 6y ago
  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.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

CurtHagenlocher 6y ago

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.

rightbyte 6y ago
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.
- tikkabhuna 6y ago
  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.

1f60c 6y ago

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-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

yjftsjthsd-h 6y ago
> 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.
- joosters 6y ago
  ... 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...
  - yjftsjthsd-h 6y ago
    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.
- 1f60c 6y ago
  I thought BitKeeper was the main repo and CVS was the mirror?
  - yjftsjthsd-h 6y ago
    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.