Wow.
Note that the official github account on which the repo was hosted has been taken down: https://github.com/tukaani-project/xz
This is serious stuff here.
Yupp
But if correct ... Then "adding" "extra key-sigs" to SSH ...
IS SERIOUSOne can only wonder :
WHY did the Author(s) do it ? - Especially if it's an inside job ...
Smells somewhat of "3 letters" from whatever country.
From comments in the above faq:
One can only wonder : WHY did the Author(s) do it ? - Especially if it's an inside job ...
It wasn't the original maintainer, but someone called 'Jia Tan' (joined the project two years ago).
Smells somewhat of "3 letters" from whatever country.
Indeed! From all the information available I see many hints pointing to a long term covert operation of a state actor. And in this case the collateral damage would have been HUGE. Luckily Andres came across the backdoor early before the new xz-util version could go mainstream. They even tried to push v5.6.1 for several linux distributions. We have to be more cautious and diligent with checking code commits, no matter if its a large and critical project or some tiny and boring one.
Every time an exploit or attack happens that receives wide attention we are told it was "very sophisticated" one created by an army of uniformed people from an evil state. After the hype dies it turnes out that it was done by a bored 16 year old kiddy in grandmo's basement.
Every time an exploit or attack happens that receives wide attention we are told it was "very sophisticated" one. After some time it becomes known that it was done by a 16 year old kiddy.
I don't have that impression. Most attacks or exploits don't make it into mainstream media anyway, and stay in the admin or security world. At the moment mainstream media reports primarily about new victims of crypto trojans. There were only a few reports about recent Microsoft disasters (in reality MS needs to be considered totally compromised). I'd say that the largest chunk of attacks is performed by cybercriminals, followed by state actors or state sponsored groups, some hackers (for fun and fame), script kiddies trying to become hackers, and at last the odd 16 year old. I can hardly imagine a 16 year old kiddy playing with m4 (a macro language, well known to sendmail users, used for the xz-utils backdoor).
I can hardly imagine a 16 year old kiddy playing with m4 (a macro language, well known to sendmail users, used for the xz-utils backdoor).
Me neitherI'm using sendmail.
And after reading the "Bat book" ... I
still think that when Stallman wrote m4 he must have been "on mushrooms" ... (Read as a joke)
Unofficial discussions on Debian downgrading to 5.3.1
If 5.4.x is hit too by something ... They committed 700+ patches "there"
Then my DEB12's are at risk
No need to panic! Let's wait and see what code reviews will dig up. Those 700+ commits could be real fixes, improvements, added features and so on. And we also don't know yet what the concrete impact on sshd is. But I agree that a reasonable precaution would be to limit ssh access.
Debian team was quick to push a fix.
I love the version number:
$ apt show xz-utils
Package: xz-utils
Version: 5.6.1+really5.4.5-1
changelog:
xz-utils (5.6.1+really5.4.5-1) unstable; urgency=critical
* Non-maintainer upload by the Security Team.
* Revert back to the 5.4.5-0.2 version
-- Salvatore Bonaccorso <carnil@debian.org> Thu, 28 Mar 2024 15:59:38 +0100
Debian team was quick to push a fix.
I love the version number:
$ apt show xz-utils
Package: xz-utils
Version: 5.6.1+really5.4.5-1
If it's 5.4.5.x+ that's affected.
Then my Deb12's
xz --version
xz (XZ Utils) 5.4.1
liblzma 5.4.1
Are in the clear ... for now
If it's 5.4.5.x+ that's affected.
5.6.0+, as far as the backdoor in question is considered.
Then my Deb12's
xz --version
xz (XZ Utils) 5.4.1
liblzma 5.4.1
Are in the clear ... for now
Yes, for now. It remains to be seen if any of the code committed by that person has other vulnerabilities. As far as I understand, the original author is currently reviewing all of those commits.
I wonder if force pushes were allowed on that repo. If they were, it'll make audit much more complicated.
The attacker was very focused at what they did, so many distributions may be unaffected even if they ship 5.6 branch. For example on Arch Linux sshd is not even using liblzma. The author might’ve hidden more surprises, but for now there is no indication other commits were malicious. It’s possible they either used them to build reputation or the identity was stolen.
It’s also worth noting that xz was affected, but the person was active elsewhere too. Code they experimented with included LZ4, libarchive, zstd (Meta) and Microsoft docs. They didn’t commit to these repos, but the bullets might’e missed us by inches. They also worked with many unspecified proprietary repositories.
In general I’d say it’s best to let the dust settle and wait for the news from people, who are currently working on resolving the issue. Sensationalism isn’t serving anybody in this case. At worst it may open opportunities for FUD or be noticed by general population media.
Every time an exploit or attack happens that receives wide attention we are told it was "very sophisticated" one created by an army of uniformed people from an evil state. After the hype dies it turnes out that it was done by a bored 16 year old kiddy in grandmo's basement.
These two are not mutually exclusive. Perhaps wearing an uniform in grandma’s basement may be inconvenient, but don’t get carried away with the perfection level achieved in government agencies. It’s primarily a matter of organisation, funding and coördination, not personal skills.
The sophistication level is in this case in plain sight too. That’s not an opinion of anonymous TV expert: what the attacker done has been outlined and you can compare that to baseline.
"Apparently". Yes, a good one to my collection of "seems to", "we speculate", "potentially", "could be", and such.
Show me the MEAT, not your creative thinking.
"Apparently". Yes, a good one to my collection of "seems to", "we speculate", "potentially", "could be", and such.
Show me the MEAT, not your creative thinking.
What got in to you ? 
Did you even read the link's
Apparently was chosen as the wording, because it has not been confirmed by others yet (single source)
Right now ... Prob only bleeding edge installs are affected.
I used buildroot a few days ago for an embedded target, and when I read about the xzutils CVE, I checked and the version reported is 5.4.4. My understanding is that buildroot pulls sources from the project's repos so would qualify as bleeding edge. Target is an iMX6, if that matters.
The attacker was very focused at what they did, so many distributions may be unaffected even if they ship 5.6 branch. For example on Arch Linux sshd is not even using liblzma. The author might’ve hidden more surprises, but for now there is no indication other commits were malicious. It’s possible they either used them to build reputation or the identity was stolen.
It’s also worth noting that xz was affected, but the person was active elsewhere too. Code they experimented with included LZ4, libarchive, zstd (Meta) and Microsoft docs. They didn’t commit to these repos, but the bullets might’e missed us by inches. They also worked with many unspecified proprietary repositories.
Yes, I'm on Arch, and xz did get affected. They let the 5.6.0 and 5.6.1 slip with this issue. It was quickly fixed though. So xz-5.6.0 is affected, xz-5.6.1-1 is affected, xz-5.6.1-2 is fixed. Check if you're concerned and if so, just update your system.
A good reminder that the human in the security chain is always the weakest link. And that when you collaborate with someone on a widely-used project, make sure you know the actual human, including real-world traceability and contact when this kind of crap occurs. A single e-mail address and connections via VPN is definitely not that.
Yeah. And people wonder/complain about why it's so "difficullt" to contribute to projects such as Linux kernel or GCC. Maybe now you realize why.
Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.
So, I don't know how to tackle this other than by strict review processes, which are very time-consuming.
Code: [Select]