Screenshot of github showing part of the commit message of this commit with this text:
Remove the backdoor found in 5.6.0 and 5.6.1 (CVE-2024-3094).
While the backdoor was inactive (and thus harmless) without inserting
a small trigger code into the build system when the source package was
created, it's good to remove this anyway:
- The executable payloads were embedded as binary blobs in
the test files. This was a blatant violation of the
Debian Free Software Guidelines.
- On machines that see lots bots poking at the SSH port, the backdoor
noticeably increased CPU load, resulting in degraded user experience
and thus overwhelmingly negative user feedback.
- The maintainer who added the backdoor has disappeared.
- Backdoors are bad for security.
This reverts the following without making any other changes:
The sentence "This was a blatant violation of the Debian Free Software Guidelines" is highlighted.
Below the github screenshot is a frame of the 1998 film The Big Lebowski with the meme caption "What, are you a fucking park ranger now?" from the scene where that line was spoken.
Tbh jia tan really wasn't lucky some mf at Microsoft noticed a 500ms delay in ssh. The backdoor was so incredibely clever and Well hidden and ingenious i almost feel bad for him lmao
I heard that person actively contributed for something like 2 years, providing actually useful contributions, to gain the level of trust needed to plant that backdoor. Feels a bit too much to chalk it up to boredom.
As for the second part, that's an interesting question. Are there lots of backdoors and we just happened to notice this one, or are backdoors very rare exactly because we'd have found them out soon like in this case?
Another speculation from the suse team was a private company with intent to sell the exploit to state across actors
I think there's lots of known backdoors that are not publicly disclosed and privately sold.
But given the history of cves in inclined to believe most come from well intentioned developers. When you read the blogs from the Google security team for example, it's interesting to see how you need to chain a couple exploits at least, to get a proper attack going. Not in this case, it would make it very straightforward to accomplish very intrusive actions.
It’s scary to think about… a lot of people are now thinking about how we can best isolate our build test process so it works as a test suite but doesn’t have any way to interact with the output or environment.
It’s just blows my mind to think of the levels of obfuscation this process used and how easy it would be to miss it.
I'm surprised that nobody suggested that he was a kidnapped dev. This seems like a different implementation of the pig butchering scams that target ordinary people.
A good chunk of scam calls and texts come from people who themselves are victims of kidnapping. Many of those victims (primarily in Asia) got into the position they were in because they were looking for work, went to a different country to start a promised job, and then got trapped and forced to work for scam centers that do social engineering attacks.
These scam centers are sophisticated to the point where they can develop very legitimate-looking crypto trading platforms for targets in the US and other wealthy countries. They then assign one of the kidnapped people to a target. These kidnapped people then social engineer their way for months to get what their captors want - usually money in the aforementioned trading platform. Then, they cut all contact once they have control of the funds.
How does this relate to XZ? Well, if they can kidnap ordinary people looking for jobs, there's not much stopping them from including devs in their pool of targets. Afterward, it's just a rinse and repeat of what they'd done before.
If you want to look more into pig butchering, John Oliver has a great episode on it.
Neither does the blob it downloaded. Would you think twice about AVX10 support if it was commented as AVX10 support in a compression library? Some might, but would they be the ones reviewing the code? A lot of programs that can take advantage of "handwritten" optimizations, like video decoders/encoders and compression, have assembly pathways so it will take advantage of the hardware when it is available but run when it isn't. If the reviewers are not familiar with assembly enough something could be snuck in.
systemD is using dlopens for libraries now and I am not convinced malware couldn't modify the core executable memory and stay resident even after the dl is unloaded. Difficult, yes, but not impossible.