Don't forget all of this was discovered because ssh was running 0.5 seconds slower
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Half a second is a really, really long time.
Technically that wasn't the initial entrypoint, paraphrasing from https://mastodon.social/@AndresFreundTec/112180406142695845 :
It started with ssh using unreasonably much cpu which interfered with benchmarks. Then profiling showed that cpu time being spent in lzma, without being attributable to anything. And he remembered earlier valgrind issues. These valgrind issues only came up because he set some build flag he doesn't even remember anymore why it is set. On top he ran all of this on debian unstable to catch (unrelated) issues early. Any of these factors missing, he wouldn't have caught it. All of this is so nuts.
Postgres sort of saved the day
Is that from the Microsoft engineer or did he start from this observation?
Thank you open source for the transparency.
This is informative, but unfortunately it doesn't explain how the actual payload works - how does it compromise SSH exactly?
It allows a patched SSH client to bypass SSH authentication and gain access to a compromised computer
From what I've heard so far, it's NOT an authentication bypass, but a gated remote code execution.
There's some discussion on that here: https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
But it would be nice to have a similar digram like OP's to understand how exactly it does the RCE and implements the SSH backdoor. If we understand how, maybe we can take measures to prevent similar exploits in the future.
I think ideas about prevention should be more concerned with the social engineering aspect of this attack. The code itself is certainly cleverly hidden, but any bad actor who gains the kind of access as Jia did could likely pull off something similar without duplicating their specific method or technique.
Somebody wrote a PoC for it: https://github.com/amlweems/xzbot#backdoor-demo
Basically, if you have a patched SSH client with the right ED448 key you can have the gigged sshd on the other side run whatever commands you want. The demo just does id > /tmp/.xz
but it could be whatever command you want.
I do believe it does
There is RedHat's patch for OpenSSH that adds something for systemd, which adds libsystemd as dependency, which has liblzma as its own dependency.
If this was done by multiple people, I'm sure the person that designed this delivery mechanism is really annoyed with the person that made the sloppy payload, since that made it all get detected right away.
I like to imagine this was thought up by some ambitious product manager who enthusiastically pitched this idea during their first week on the job.
Then they carefully and meticulously implemented their plan over 3 years, always promising the executives it would be a huge pay off. Then the product manager saw the writing on the wall that this project was gonna fail. Then they bailed while they could and got a better position at a different company.
The new product manager overseeing this project didn't care about it at all. New PM said fuck it and shipped the exploit before it was ready so the team could focus their work on a new project that would make new PM look good.
The new project will be ready in just 6-12 months, and it is totally going to disrupt the industry!
I see a dark room of shady, hoody-wearing, code-projected-on-their-faces, typing-on-two-keyboards-at-once 90's movie style hackers. The tables are littered with empty energy drink cans and empty pill bottles.
A man walks in. Smoking a thin cigarette, covered in tattoos and dressed in the flashiest interpretation of "Yakuza Gangster" imaginable, he grunts with disgust and mutters something in Japanese as he throws the cigarette to the floor, grinding it into the carpet with his thousand dollar shoes.
Flipping on the lights with an angry flourish, he yells at the room to gather for standup.
Cigarette is stomped.
Stickies fall from kanban board.
Backdoor dishonor.
In a nutshell you say...
Coconut at least...
A small blurb from The Guardian on why Andres Freund went looking in the first place.
So how was it spotted? A single Microsoft developer was annoyed that a system was running slowly. That’s it. The developer, Andres Freund, was trying to uncover why a system running a beta version of Debian, a Linux distribution, was lagging when making encrypted connections. That lag was all of half a second, for logins. That’s it: before, it took Freund 0.3s to login, and after, it took 0.8s. That annoyance was enough to cause him to break out the metaphorical spanner and pull his system apart to find the cause of the problem.
The post on the oss is more detailed and informative
The scary thing about this is thinking about potential undetected backdoors similar to this existing in the wild. Hopefully the lessons learned from the xz backdoor will help us to prevent similar backdoors in the future.
I think we need focus on zero trust when it comes to upstream software
did we find out who was that guy and why was he doing that?
We probably never will.
If we ever do, it'll be 40 or 50 years from now.
Probably a state actor
Any additional information been found on the user?
Probably Chinese?
They're more likely to be based in Eastern Europe based on the times of their commits (during working hours in Eastern European Time) and the fact that while most commits used a UTC+8 time zone, some of them used UTC+2 and UTC+3: https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and
It is also hard to be certain as they could be a night owl or a early riser.
Just because somebody picked a vaguely Chinese-sounding handle doesn't mean much about who or where.
That's why I put the question mark
as long as you're up to date on everything here: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
the only additional thing i've seen noted is a possibilty that they were using Arch based on investigation of the tarball that they provided to distro maintainers
At least microsoft is honest enough to admit their software needs protection, unlike apple and unlike most of the people who have made distros of linux. (edit: microsoft is still dishonest about what kind of protection it needs though)
Even though apple lost a class action lawsuit for false advertising over the claim "mac can't get viruses" they still heavily imply that it doesn't need an antivirus.
any OS can get infected, it's just a matter of writing the code and finding a way to deliver it to the system....Now you might be thinking "I'm very careful about what I click on" that's a good practice to have, but most malware gets delivered through means that don't require the user to click on anything.
You need an antivirus on every computer you have, linux, android, mac, windows, iOS, all of them. There's loads of videos on youtube showing off how well or not so well different antivirus programs work for windows and android.
A "antivirus" tends to be a proprietary black box. Such "antivirus" programs could not of detected the XZ backdoor
This whole situation just emphasizes the fact that rebasing >>>>>>>>>> merge squashing.