Hacker News Reader

Comment by benlivengood | Hacker News Reader

The only upside of finding this attack (aside from preventing it from being rolled out more widely) is that it gives a public example of a complex APT supply-chain attack. Rest assured there are more out there, and the patterns used will probably be repeated elsewhere and easier to spot.

Obfuscated autoconf changes, multi-stage deployment, binary blobs (hello lib/firmware and friends, various other encoders/decoders, boot logos, etc), repo ownership changes, new-ish prolific committers in understaffed dependency libraries, magic values introduced without explanation.

View on HN

Add to that list suppression of warnings from valgrind and address sanitizer without any justification. And no tracking issue to follow up on fixing the problem so the suppression can be removed.

Committing binary files to source control rather than including build commands to generate the files is a bit of a red flag.

They're test cases for a compression library. Seems pretty reasonable.

Not at all. This would not pass a good code review. The test was for good stream, bad stream, good stream. The two good streams were only a few bites, why was the bad stream so large?

A good reviewer should have, even for a binary test case, asked the submitter to simplify it to the smallest or most basic binary required for the functionality.

idk picking a real-world example that breaks the code seems like a good test case to me

It is a good example for an initial bug report but, once the code has been fixed to handle that failure case, minimal examples are the correct lasting tests to live with the code forever.

Additionally, a complex example may require multiple conditions to fail and if those aren't split into multiple tests then subtle bugs can be reintroduced later because that complex test doesn't cover all potential failure conditions. If there need to be test cases for multiple related bugs then they need to be minimal to demonstrate the failure condition combinations they are testing for.

Adding a script to regenerate good and bad binary files might have worked for this use case pretty well too.

> The changes to build-to-host.m4 weren't in the source repo, so there was no commit. > > The attacker had permissions to create GitHub releases, so they simply added it to the GitHub release tarball.

What are some simple tweaks the "Debians" of the world can do to mitigate this kind of stuff?

Not trust "hand-curated-by-possibly-malicious-maintainers" GitHub release tarballs, only trust git commits?

Whitelist functions that are allowed to do IFUNC/ELF hooking to core OpenSSH functions?

Read IOCCC entries.

Now realize, those are people having FUN. What is your chance of catching nation state level maliciousness in a codebase? Pretty low.

remove test blobs before building

What's a test binary? Bunch of bytes on disk. What's a source file? Bunch of bytes on disk.

Good people and bad people are all made of atoms so there's no difference.

I think the point is that you can't tell a good person from a bad one by inspecting the atoms.

binary files can be distinguished from text files with good enough confidence.

folders containing test files could easily be removed before build just by name or should live in a separate repository altogether.

A text file can contain a malicious payload in exactly the same way a binary file can.

If you want to get paranoid about a test subdirectory, stash the payload in comments or formatting choices in the source code itself.

It's great to say "aha, this particular exploit would be deleted by not having binary files in a test directory!", but that totally misses the point that you can put the bytes you want in other places, such as in the source code which is itself a load of bytes. See also polyglot programs and the code is data premise.

What point are you arguing here? More binaries rather than less? Less readable source code rather than more readable? That we should just give up because some people manage to win underhanded C contests? Are you arguing that binaries are equally easy to understand and dissect as source code that has to follow some syntax?

> a complex APT supply-chain attack

What do you mean by APT? If you mean Debian's package manager, that's not what this attack was. This was done upstream and affected non-apt distros just as much.

It's true that upstream is part of apt's supply chain but focussing on apt is misleading.

edit: why the downvotes? I get from the responses that I was wrong but given how the exploit was initially found in a Debian system and a lot of people very quickly jumped on the “Debian patched a thing and broke security” bandwagon, I don’t think it was much of a leap to wonder if that’s what was meant.

Acronyms and initialisms are not the best way to convey specific information.

Not apt the package manager-- it's an acronym for Advanced Persistent Threat

> What do you mean by APT

Advanced, persistent threat.

It stands for “Advanced Persistent Threat” - https://en.m.wikipedia.org/wiki/Advanced_persistent_threat

I think Advanced Persistent Threat.

Others have answered your question about APT but FWIW I don't understand the downvotes. You were respectful and simply sought to clear up a misunderstanding.

I was heavily downvoted for supplying a link to a previous discussion on the same topic recently. I wouldn’t worry much about it.

> hello lib/firmware

How could it play any role here? It doesn't bring any dependencies, does it?

Reply on news.ycombinator.com