More like
CHINA AGENT JO
Frankly, I’d be shocked if this wasn’t related to Chairman Winnie and the CCP.
3 Likes
Both variants are equally plausible! 
2 Likes
Could be:
NIGHTCANE JAO
2 Likes
Perfect timing 
I wonder why… 
1 Like
try uninstalling xz package 
please simple do NOT try that!!!
Would lead to a very secure system indeed…
1 Like
Naaah i’m good with my os
P.S. Funniest thing ever is that even zstd requires it…which is WHY?! 
1 Like
4 Likes
Maybe xz backdoor was made particularly for zstd?
2 Likes
Well this backdoor is really intimidating. I’m pretty sure, that the creator didn’t limit his actions to xz. I’m really concerned what will be found in the next days, weeks.
It would have been everywhere as time passed by. And that it has been discovered is kinda a lucky punch.
2 Likes
the end result will be a more secure OS with more people paying attention to the code
Hopefully. This backdoor gives access to everything and finally is the biggest possible killswitch one actor could use.
Desktop Linux is a niche, but as a widely used sever os it runs critical infrastructure.
After reading 40 things I’m more confused but still its mind-blowing.
After XZ was hijacked from creator “lasse”, new maintainer “Jia” begged, cajoled, pleaded his way into the big hearts (repos) of Debian and Red Hat.
The Big Hearts at Deb and RH had XZ/or XZ library tentatively scheduled for repo inclusion.
There was no payload yet.
But there was a backdoor built.
All that “Jia” was probably waiting for mass distribution of the product to release payload thereby creating the biggest amt of damage)?
Do I have that right?
2 Likes
We are lucky that most lts/enterprise versions didn’t pickup the malicious package versions yet. So mostly bleeding edge installations were backdoored. But time passing would have changed that.
The payload was hidden in the connection certificate if I got it correctly. So the actor could exploit every system running a ssh service reachable from the internet at any time he wanted, as far as the malicious version of xz was installed. Correct me if I’m wrong.
If you’re familiar to portscanning, you’ll realize that ssh sadly is a very common service that is exposed to the internet (bad practice btw). So the possibilities for an attack could have been huge.
1 Like
I think you read the situation the same way I do. It was a tick-tick-tick situation–and I did omit SSH was the exploitable vector here, you are right. I didn’t read it was the connection certificate, my understanding the backdoor was created in the purposeful sabotage (downgrade to unsafe libraries) of xz internal code. Maybe we are both right.
1 Like
I like to think positively. We dodged a bullet and the guy was just playing the long term game. There are lessons to be learnt from this, for sure.
1 Like
Despite it’s malicioous nature the technical aspects of this attack are very impressive.
I am lucky to compile some tiny C source code without an error and there are people out there who are thinking in such a way… 
1 Like
Yes, if you make a brilliant backdoor, use it quickly, before it gets discovered.
5 Likes
Or optimise your backdoor process so it does not take 0.5s longer to login via ssh.
7 Likes
that .5s was the thing that brought the caper down 
1 Like