5 ms·
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-ch
by benlivengood 3y ago
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.
- cassianoleal 3y ago> 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.
- mttpgn 3y agoNot apt the package manager-- it's an acronym for Advanced Persistent Threat
- supriyo-biswas 3y ago> What do you mean by APT Advanced, persistent threat.
- haimez 3y agoIt stands for “Advanced Persistent Threat” - https://en.m.wikipedia.org/wiki/Advanced_persistent_threat https://en.m.wikipedia.org/wiki/Advanced_persistent_threat
- microtonal 3y agoI think Advanced Persistent Threat.
- deleted 3y ago[deleted]
- nequo 3y agoOthers 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.
- macintux 3y agoI was heavily downvoted for supplying a link to a previous discussion on the same topic recently. I wouldn’t worry much about it.
- MuffinFlavored 3y ago> 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?
- ilc 3y agoRead IOCCC entries. Now realize, those are people having FUN. What is your chance of catching nation state level maliciousness in a codebase? Pretty low.
- heeen2 3y agoremove test blobs before building
- JonChesterfield 3y agoWhat's a test binary? Bunch of bytes on disk. What's a source file? Bunch of bytes on disk.
- varjag 3y agoGood people and bad people are all made of atoms so there's no difference.
- evilos 3y agoI think the point is that you can't tell a good person from a bad one by inspecting the atoms.
- heeen2 3y agobinary 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.
- MarkSweep 3y agoAdd 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.
- saagarjha 3y agoThey're test cases for a compression library. Seems pretty reasonable.
- hyperhopper 3y agoNot 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.
- saagarjha 3y agoidk picking a real-world example that breaks the code seems like a good test case to me
- benlivengood 3y agoIt 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.
- Dunedan 3y ago
- deleted 3y ago[deleted]
- fsflover 3y ago> hello lib/firmware How could it play any role here? It doesn't bring any dependencies, does it?