Tootfinder

In my experience Russ Cox is always worth reading. But… in this case, only if you’re up to looking at extremely gnarly shell/sed/awk/etc incantations. These attackers were serious. #xz
https://social.afront.org/@pba…

I've been wondering what, if any, sort of risk Lasse Collin might have been exposed to no one else would see.
For example, was there a malicious private branch Lasse tested? Reportedly JT and Lasse communicated mostly over Signal. Were any links shared and clicked on?
This edges on fantasy and conspiracy theory, but I'm hoping Lasse thinks deeply about this if he hasn't already. #xz

That escalated quickly: The #xzbackdoor caused the first domain registration: #xz

The security of the worldwide information technology infrastructure sadly rests on tons of unpaid open source developers. 😦
https://www.theverge.com/2024/4/2/24119342/xz-utils-linux-backdoor-attempt

How one volunteer stopped a backdoor from exposing Linux systems worldwide
A maintainer for a Linux-based database identified malicious code hidden in a tool called XZ Utils and stopped a global security breach in its tracks.

Morgenlektüre gefällig? @… hat zusammengetragen was wir über #xz und den Angriff auf praktisch alle ssh-Logins weltweit wissen.

This is a fascinating glimpse into the *beginning* of the #xz exploit, i.e. the social engineering.
Some users (accomplices of the attacker?) used the dev mailing list to badger and harass the maintainer of the project who was on the verge of burnout, to pressure him to grant co-maintainer status to the attacker.
Whether this was part of the attack or not, it’s a sad glimpse into the toxic pa…

Gute Zusammenfassung des #xz-Fiaskos
https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/

OK, I think that this, from @…, is probably a good choice as an #xz “hub” document. It’s excellent and includes links to all the other real high-quality analysis that I’ve seen:

@… #xz, xv, who's counting?

Heise berichtet nun auch (inkl. Link zu einem Erkennungsskript):
Hintertür in #xz-Bibliothek gefährdet SSH-Verbindungen | heise online
https://www.

Wir sind dieses Wochenende nur durch unglaubliches Glück und extrem knapp an wohl einer der grössten Katastrophen rund um die globale IT-Sicherheit vorbeigeschrammt.
Phuh! Doch — was ist eigentlich passiert? Wie konnte das überhaupt geschehen? Und was können (und müssen) wir tun, um dies zukünftig zu vermeiden?
Und: Danke an die ganzen IT-Helden, die dies an diesem langen Wochenende für uns getan haben.

Lasse Collin's patch-series updating the #LinuxKernel's #xz code that a few days ago hit #linux-next was dropped for now until backdooring of upstream xz is understood better:

My takeaway from the #xz backdoor is that I will now treat any and all “is this still being maintained”-esque messages in open source repositories with the hostility merited a nation-state supply-chain attack on open source as a concept.

Unsurprisingly, Lasse Collin says he has had no contact with any law enforcement.
I wouldn't expect law enforcement to just show up and start questioning him. Which LE? On what basis and authority? The investigation will almost assuredly be largely done by some core coders, numerous nerd-oriented amateur sleuths, and a small handful of tech reporters.
#xz

If something like that comes from a person like @… , the #FOSS community should listen carefully.
In particular after incidents like #xz and

I updated it so you don't have to.
#xz #xzbackdoor

Looks like there has been a long game to introduce an SSH exploit through #xz / #liblzma.
Details on which systems are at risk here:
https://

liblzma and xz version 5.6.0 and 5.6.1 are vulnerable to arbitrary code execution compromise - Xe Iaso

What we know about the #xz Utils #backdoor that almost infected the world
On Friday, a developer rocked the world when he revealed a backdoor had been intentionally planted in xz Utils, an #opensource

@… #xz, xv, who's counting?

Oh yeah, I forgot that I cloned the #xz repo last week. I wonder if I should upload it somewhere?

I guess some responsible adult is going to get landed with the xz repo maintenance and release, of which the first act would be to get the security review done and not presume that the first commit from the suspects is actually the first commit.
Who decides?
#xz #xzBackdoor

People are afraid of running unaudited `curl | sh`, but nobody bats an eye on 24707 lines of obfuscated garbage in `./configure`.
#xz

#XZ #vulnerability according to redhat this vulnerability comes after 5.6 mine looks fine
https://acces…

excellent analysis of the backdoor initial stages: #xz

xz/liblzma: Bash-stage Obfuscation Explained

Lotta people talking about preventing the next #xz and I gotta say, it's an extremely bold assumption that we shouldn't instead be thinking about finding the other existing xzs.

The #xz / #openssh / #systemd supply chain attack is, to me, a great example of why Unix-like systems (such as Linux) should stick to the approach of small, simple, focused, applications.
I've never been a …

Am dritten Tage mask-removed von dem Testing, downgegraded zu dem Stable; er lasse die Finger von SSH, des verschlüsselten Zugriffs. Denn dort wirds sonst brechen die Testenden und das Prod.
#xz #ITOstern

What strikes me particularly negatively about the current #xz backdoor is how apparently difficult it is for some large accounts to share other toots. They often prefer to repeat the same content in their own words so as not to give anyone else any reach. This behavior is annoying for readers because the same link always appears in the same posts, but from different people in the timeline. …

Recently began reading "Fancy Bear Goes Phishing: The Dark History of the Information Age, in Five Extraordinary Hacks" #xz would fit in quite well, too…

This is brutal. I was shocked that the obvious vandalism is so hard to see, and then my brain immediately turned to other ways to accomplish the same thing even more discreetly, and a few of the things I thought of made me want to puke.
#xz #infosec

One thing I have yet to see much of in this #xz debacle is much if any empathy for the original project maintainer. From what I can gather they’ve been toiling away on this project for at least 2 decades, have faced mental health issues in that time that required them to take breaks from it, and that the alleged hacker potentially conned their way into a position of authority for the project.
I can…

I'm going to stop re-tooting about the #xz #backdoor as I'm pretty sure everyone is aware now. I'm sure there will be further analysis and recommendations in the following days and hopefully concrete action other

For anyone who has missed it: One of the maintainers of xz/liblzma (& libarchive?) has apparently been backdooring it for a couple of years. Fortunately it seems to only target Debian-based distros!? So once again I luck out with my oblivious computing choices, having almost everything personally and professionally either EL-based or BSD-based
#InfoSec

I do have an idea for the #xz maintaining problem. We should treat binary blobs in repos and PR like email attachments: viruses until proven otherwise.
Github providing an integrated antivirus could be better than nothing.
(This is NOT a complete solution, but could help).

Details on the #backdoor in #xz for users of #Fedora 40 and 41/rawhide:

Perplexity.ai is getting pretty good at answering questions about developing situations.
#ai #xz

Based on their analysis of working hours, timestamps, and holidays, it seems likely "Jia Tan" worked out of Eastern Europe or Russia while doing the #xzBackdoor ⬆️.
Clever analysis by Rhea Karty and Simon Henniger.
#xz
https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and

Does anyone know or have any suspicions of who is behind the #ssh #xz backdoor? I'm unable to find anything about that.

#xz

1/2 If you don’t want to read about the #xz backdoor-related stuff I advise muting the hashtag because a *lot* of people across the geek spectrum find this whole thing fascinating and very educational.
My latest educational read has been the discussion over in the Debian world at

Popular compression tool #xzutils containing #malware seems like a biggie. I am unable to find a website with details, so I am quoting from the e-mail that was sent to debian-security-announce@lists.debian.org:
Package: xz-utils
CVE ID: CVE-2024-3094
Andres Freund discovered that the …

lol, the #ReproducibleBuilds people are finally having their day in the sun
(and hey good for them, they've done a lot of work to get to this place!)
#xz #XzBackdoor

One thing that’s bugging me about the theories around the #openssh / #xz back door is that it was orchestrated by “a foreign government”.
*If* it was a government, then it’s not a foreign government to everyone. Some folk will live in the country where that government is in control, and, as things stand,…

So the #xz wasn't an April Fool that went off prematurely...

A new paper with our current findings on the #xz case and potential mitigations is now online at @…: https://arxiv.org/abs/2404.08987
Please treat as work-in-progress, and there are multiple lines of analysis that we are still following up on. A future submission of an extended version to a peer-reviewed venue is quite possible.

Perplexity.ai is getting pretty good at answering questions about developing situations.
#ai #xz

makes sense, actually
#xz

Details matter! Clifford Stoll identified a KGB attacker by looking at an accounting error of 75 cents, @… found a well-planed ssh attack by investigating unexpected CPU spikes.
#security

1/2 Looking at one of the #xz writeup, this struck my eye: “The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf.” Ah, GNU AutoHell, I remember it well. Tl;dr: With AutoHell, even if you're building for a 19-bit Multics variant from 1988, it’s got yo…

Unconfirmed: The Jia Tan persona may have chatted with #xz's Lasse Collin primarily over #Signal, as opposed to IRC or some other medium. It is probably impossible to read much into that if true, and may be impossible to ever deduce much about this story from it, but if confirmed, this would be a useful bit of information.

So the #xz wasn't an April Fool that went off prematurely...

Of course, I can't start a day without being awfully angry about some shit.
So #Gentoo suddenly undoes USE=lzma [and USE=zstd] that used to be enabled by default in 23.0 profiles, apparently based on "consensus" on the mailing lists. The "consensus" boils down to one conspiracy theorist developer complaining, and being supported by 3 users whose Gentoo contributions boil down to having to express their opinions on everything on the mailing list.
This isn't only a problem, because Gentoo is letting itself be controlled by a vocal minority. This is a problem, because we've enabled something that can affect program output, told everyone to upgrade and rebuild their systems, then pulled the carpet from under them.
Wait, did that random app start using LZMA compression now that you've enabled it? Well, bad luck, you won't be able to open your files anymore. Surely, there's no better #security than not being able to do anything!
Unfortunately, sys-apps/kmod had explicit IUSE= lzma by default for a while now, so there's still a risk that you'll be able to boot your system. That's not good for security at all!
#xz

Inzwischen gibt es Demo-Code, mit dem jede Applikation ohne die ganzen #xz-Abhängigkeiten `systemd`-Notifications versenden können. Danke, @… !
https://mastodon.social/@pid_eins/112202687764571433

Oh, btw: I was just made aware of a 4½ minute video that summarizes most of the events and has (what I greatly appreciate) some great real-world analogy for how the backdoor was installed and then detected. Enjoy!
#xz #xzBackdoor
https://www.youtube.com/watch?v=bS9em7Bg0iU

Lasse Collin added a few updates to #xz

Second-order effect of #xz-utils: Should we report this YouTube channel for #misinformation? Or is it just a very bad habit from good intentions? #infosec

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…

The xz backdoor seems to be in all Linux distributions, and given it's in MacOS it's highly likely to be in *bsd as well.
The Good Thing is that those that need to have down graded repositories, so just do whatever flavour of update and it will be fine.
#xzBackdoor

This couldn't be more relevant with the #xzbackdoor being discovered just recently.
Please note there will be a panel discussion on the XZ event this evening at 18:00 in the ring arena. #javaland
Correction: this panel will take place at 18:00 CET.

The #xz utils repo has returned with an update https://github.com/tukaani-project/xz

The xz backdoor seems to be in all Linux distributions, and given it's in MacOS it's highly likely to be in *bsd as well.
The Good Thing is that those that need to have down graded repositories, so just do whatever flavour of update and it will be fine.
#xzBackdoor

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…

What if a bunch of Linux distros like Debian testing and Fedora 40, along with every rolling distro got a backdoor
Oh... #backdoor #xz #liblzma #linux #ArchLinux

Eine Bekannte hat mich auf den gut gemachten #xz-Artikel bei #Bluewin News aufmerksam gemacht. Gut verständlicher Überblick mit vielen interessanten Punkten. Wenn ihr in eurem Bekanntenkreis also etwas teilen wollt, das zwischen den vielen sehr oberflächlichen Artikeln da draussen eine Alternative ist,…

«Die Feiertage. Die ganzen IT-Abteilungen feiern mit der Familie… Die ganzen IT-Abteilungen? Nein! Eine von unbeugsamen Open-Source-Enthusiasten bevölkerte Mailingliste hört nicht auf, den Eindringlingen Widerstand zu leisten.»
Wie die Open-Source-Gemeinde über Ostern in letzter Minute eine riesige, von langer Hand vorbereitete Sicherheitslücke (#Backdoor) entschärft hat.
#xz #OpenSource #OSS #FOSS #FLOSS
📰 https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/
🧵 https://waldvogel.family/@marcel/112199949979360732

«Die Feiertage. Die ganzen IT-Abteilungen feiern mit der Familie… Die ganzen IT-Abteilungen? Nein! Eine von unbeugsamen Open-Source-Enthusiasten bevölkerte Mailingliste hört nicht auf, den Eindringlingen Widerstand zu leisten.»
#xz #xzbackdoor #lzma #ssh
https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/