5 ms·

So the attacker put the payload into the tests folder of the compression library and injected it upon build via some arcane build script? Kudos. That's quite a

So the attacker put the payload into the tests folder of the compression library and injected it upon build via some arcane build script? Kudos. That's quite a smart way to hide your backdoor. Nevertheless, they got caught. So big respect for the analysis. Amazing work. That being said, what does this attack tell you about the future of software security? Free software could easily be compromised by having a highly paid team create such a payload and then convince some maintainer, one way or another, to deploy it. How do we back off from that cliff?

cassianoleal 3y ago
Security is hard. In this case, it seems like there's a lot that could be done to reduce the chance of being exploited. Why are obscure binaries in the repository at all in the first place, even if in the test dir? Surely those binaries can be generated as a setup step prior to the tests actually running. Furthermore, why are there scripts present in the release package that have not been added to the source code? Also, if I understood it correctly, the compromised binaries are also present in the release tarball. Why are they part of the release if they are supposedly test fixtures rather than part of the application code?
- cesarb 3y ago
  > Why are they part of the release if they are supposedly test fixtures rather than part of the application code? Test fixtures should be distributed together with the application code, so that the actually built application can be tested. Ideally, the application should be tested every time it's built, to ensure that for instance a change in the compiler being used didn't break it.
  - cassianoleal 3y ago
    Thanks, that makes sense. I think in my mind the whole chain was still source code->compile->test->distribute from a single repo which is obviously not the case. It’s more like source->package->test->ship to distros->compile->test->package->distribute
jethro_tell 3y ago
To be fair, so could closed source code. The difference in this case is that a guy was running perf tests against postgres and noticed his ssh was slow, so he dove into that and found the backdoor a couple days after it was pushed. If you had to submit 'my ssh daemon is slow' to a third party it would get put on the pile with the rest of them
- bee_rider 3y ago
  Hmm, well they never find these kinds of attacks in closed source code. OTOH they never find these kinds of attacks in closed source code!
- wolverine876 3y ago
  Closed source is a little tougher: Often you need to get a job somewhere in their organization or supply chain.
  - bashtoni 3y ago
    Or find a security vulnerability in their network, say a poorly secured FTP server as per SolarWinds.
    - shrimp_emoji 3y ago
      And then you wouldn't have random people discovering it! It could even be covered up indefinitely.

cassianoleal 3y ago

Security is hard. In this case, it seems like there's a lot that could be done to reduce the chance of being exploited. Why are obscure binaries in the repository at all in the first place, even if in the test dir? Surely those binaries can be generated as a setup step prior to the tests actually running. Furthermore, why are there scripts present in the release package that have not been added to the source code? Also, if I understood it correctly, the compromised binaries are also present in the release tarball. Why are they part of the release if they are supposedly test fixtures rather than part of the application code?

cesarb 3y ago
> Why are they part of the release if they are supposedly test fixtures rather than part of the application code? Test fixtures should be distributed together with the application code, so that the actually built application can be tested. Ideally, the application should be tested every time it's built, to ensure that for instance a change in the compiler being used didn't break it.
- cassianoleal 3y ago
  Thanks, that makes sense. I think in my mind the whole chain was still source code->compile->test->distribute from a single repo which is obviously not the case. It’s more like source->package->test->ship to distros->compile->test->package->distribute

jethro_tell 3y ago

To be fair, so could closed source code. The difference in this case is that a guy was running perf tests against postgres and noticed his ssh was slow, so he dove into that and found the backdoor a couple days after it was pushed. If you had to submit 'my ssh daemon is slow' to a third party it would get put on the pile with the rest of them

bee_rider 3y ago
Hmm, well they never find these kinds of attacks in closed source code. OTOH they never find these kinds of attacks in closed source code!
wolverine876 3y ago
Closed source is a little tougher: Often you need to get a job somewhere in their organization or supply chain.
- bashtoni 3y ago
  Or find a security vulnerability in their network, say a poorly secured FTP server as per SolarWinds.
  - shrimp_emoji 3y ago
    And then you wouldn't have random people discovering it! It could even be covered up indefinitely.