Hacker News Reader

Comment by choeger | Hacker News Reader

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?

View on HN

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

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!

Closed source is a little tougher: Often you need to get a job somewhere in their organization or supply chain.

Or find a security vulnerability in their network, say a poorly secured FTP server as per SolarWinds.

And then you wouldn't have random people discovering it! It could even be covered up indefinitely.

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?

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

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

Reply on news.ycombinator.com