What we have is an Illuminati that is using Jira. :(
NSO Group built a turing-complete VM out of a use-after-free exploit in some JBIG2 decompression code. Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison.
My best guess as to what this is is an amateur hacker ring, possibly funded by a ransomware group.
[0] https://securelist.com/operation-triangulation-the-last-hard...
[1] https://news.ycombinator.com/item?id=38783112 - HN discussion
The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.
If you look at that HN discussion, you'll find a link to a Mastodon post from an Asahi Linux developer explaining that these "S-boxes" are actually an ECC calculation, and that the registers are probably cache debug registers, which allow writing directly to the cache bypassing the normal hardware ECC calculation, so you have to do the ECC calculation yourself if you don't want a hardware exception caused by an ECC mismatch on read (of course, when testing the cache, sometimes you do want to cause an ECC mismatch, to test the exception handling).
Thankfully! At least in a democracy, the government is chosen, megacorps are accountable to no one else.
https://en.m.wikipedia.org/wiki/Apple–FBI_encryption_dispute
The quality of work you attract in part depends on how much you pay. Go check out how much is paid for a persistent iOS exploit, compared to a Linux user space exploit. From that, you may draw conclusions about their relative perceived difficulty and desirability. This will explain why iOS exploits are done more professionally. They are rarer, much better paid, and thus attract a better audience and more work on guarding them from discovery.
While the world is trying to understand the backdoor, you sir decided that it's "clowshoes". I can only blindly defer to your expertise... "Clownshoes, amateur, hacker ring, ransomeware group." Done.
> Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison.
It has to be on the world wide web for distros to package and ship it. And this was actually the best disguise possible: this directory is one where it is normal and expected to have binary files that are not obviously analyzable, as this one wasn't -- another part of the malware rearranged it to become non-corrupt at exploitation-time.
See this note from the README for the test directory:
> This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.
It is a brilliant solution to the problem of "okay, but where do I hide the malware payload, given the constraint that it has to be distributed alongside the code and tarballs?". The attack was detected, but not because of this file, and it's unlikely to me that it ever would have been detected purely by the means of this file, given the comment above.
You can't conjure quality from nothing (especially if it's pure patriotism/jingoism), large organizations are bound to work with mediocrities and dysfunctional processes, geniuses don't scale. (I feel like stating the obvious)
not sure if we should easily judge offsec and the private-public partnership that provides intel and offensive capabilities.
whether they're ex-criminals or must be accused of "dubious morals" would depend whether their clients (or targets) are what one considers the enemy.
and what about the guy who silently works on a "dubious project" patiently for years ... and then, at the right moment, knowingly throws a spanner in the works? aren't they the true hero?