Every Linux Distro Must Learn From XZ Backdoor

preview_player
Показать описание
The recent incident with XZ has garnered a lot of attention and with that hopefully is going to act as a chance to learn how to better handle future events like to further mitigate the damages

==========Support The Channel==========

==========Resources==========

=========Video Platforms==========

==========Social Media==========

==========Credits==========
🎨 Channel Art:
Profile Picture:

#Linux #Distro #OpenSource #FOSS

🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
Рекомендации по теме
Комментарии
Автор

Always good to see more awareness of Reflection on Trusting Trust. My first substantial work in C, and only substantial work in C to date, was implementing a compiler backdoor of that kind in a modified build of the Tiny C Compiler as part of a college project, and it's terrifying to me how easy to pull off it was for someone not particularly familiar with C. My EvilTCC only miscompiles the original TCC source and GNU Nano, specifically replacing the "Welcome to Nano..." help text with "Your nano has been hacked by an evil compiler." (I'm a neovim user with a weird sense of humor, and it seemed like a harmless way to see whether EvilTCC worked while dunking on Nano). I took steps to ensure that the EvilTCC compiler and all code I compiled with it stayed on my own personal laptop, but if someone with malicious intent were to do the same thing and spread it, then that would be bad.

eliminmax
Автор

Kudos to all of the great people who not only make Linux, but keep it the most wicked OS of all by keeping us users in the know, and slaying the dragons of exploits!! You are Heroes!!

Bob-of-Zoid
Автор

Cows: can be milked for a decade
XZ Backdoor:

noot
Автор

As an observation, this did actually 'bleed' into other Distros. I was building a custom ISO of Majaro in early March, and noted very 'odd' installer behavior during testing.
The Calameres installer would usually show the number of files being unpacked; however I only ever got an ambiguous "Filling up filesystems." - no other status.
After sharting myself during the XZ expose - I rebuilt my 'distro' to get rid of this threat, which I confirmed to exist by checking my packages list.
Now the installer runs normally, with the usual "Unpacking file x of ##" counting up as it completes.
Also, even though there was also a kernel update when I made this; the whole ISO is about 30MB smaller than it's 'infected' beta, but it's hard to isolate such a small change in a 5.4GB file...

Vilvaran
Автор

Kudos to Brodie for not letting Suse off the hook at the end. Truth of the matter is that where "many eyes" was present the backdoor was caught. Where "many eyes" was not present, i.e. the tarball and the non-human readable binary files, the backdoor remained unnoticed. Also distros need to stop blindly trusting upstream developers. They are humans and could turn malicious at any point, for any odd reason.

locatemarbles
Автор

one way to get the money would be to treat the distros as a part of the supply chain as well and letting companies write contracts with them to process the same guarantees. a lot of companies depend on software that has no legal obligation whatsoever and many of them would probably like to change that if it was easy

asdfghyter
Автор

Thanks for the cover of the article and your explanations! Appreciate it ❤

Thek
Автор

I actually read that security paper back in highschool it was a topic of discussion for good reason. Ultimately we do need improved chains of communication and verification, overlooking the tarballs should be embarrassing, but there are solutions.

Remember, the community did respond to this despite the hurdles. In a corporate environment this could have been pulled from a pip repo and nobody would ever check.

orbatos
Автор

I still believe adding systemd dependencies into something vital such as openssh was a bad idea from the start. Also, certain core services should be subject to much more scrutiny when it comes to additions and changes. In fact, any service that typically runs as root should require rigorous review and design discussion before new dependencies are introduced.

ToumalRakesh
Автор

I just have to say: Thank you Brodie for highlighting and going over these articles. Sometimes it just gives them more (deserved) attention, but for this one in particular I had it open in a tab for over a week now and was simply putting off reading it indefinitely lol

mskiptr
Автор

This could have been way worse. As a Tumbleweed user, I am glad to know they took the initial warning as seriously as they did. The same goes for the Debian crew, although you don't have nearly as many people running Debian Sid. A lot of people got busy and took care of this quickly.

@Brodie, were there any victims of actual hacks from this, or was it all caught and cleaned up in time?

act..
Автор

the trusting trust thing is a good argument for trying to make the entire distros have reproducible builds. especially if you can build everything from scratch and using no blackbox binaries. in this case, opensuse could’ve rebuilt everything using a non-compromised system and see that nothing except xz itself would have changed

asdfghyter
Автор

These lessons are important, and they're not the only ones. They're the "sexy" problems. But I don't think one response to this attack is going to prevent it from happening again.

I can think of at least a couple of ways that two pieces of malicious code could communicate with each other that'd survive a code review and even perhaps a debugger when not actively being triggered, potentially with "not under a debugger" being one of the trigger conditions.

The stakes are raised and the game has gotten a lot more interesting.

knghtbrd
Автор

One of the cool tech tree items we will unlock after completing reproducibility and bootstrappability is comprehensive source auditing. There's some activity like that happening for Rust and hopefully we will be able to achieve more in this field.

Just imagine if all the distribution packages were clearly marked whether their entire dependency tree has anything unaudited in them (or how comprehensive and independent that coverage is). This is unfortunately almost impossible to complete, but getting it done for at least core packages would be awesome.

To make it more feasible, we should really start using languages that help us reduce the amount of code that really has to be inspected. Rust (with its 'unsafe' construct) gets us a long way, but you can still write exploitable bugs in safe code. To truly minimize the attack surface, we would need capabilities | managed effects instead.


There's also the auditable silicon thing, but that's sadly quite expensive. Unless someone like Google decides to invest into it or one of the smaller chip design companies tries to actually ride the hype train of RISC-V openness, we would basically need to crowdfund some low-performance CPU cores on old-tech fab nodes.

mskiptr
Автор

I really appreciate your dissection of those issues and making those not easy understandable things easy to understand. 🙂

andreasbaumann
Автор

What an interesting topic. Hadn’t heard of this xz security issue.

Dylan-zmht
Автор

OpenSUSE: "The way we've been doing things in the open-source community isn't inherently infallible and it's time to start talking about ways to improve it and prevent social engineering attacks in the future."
Brodie: "That's very reasonable and it's good they're saying it."
YouTube comments: "OK BUT WHAT ABOUT WINDOWS"

What ABOUT Windows? State actors are trying to sabotage Linux now, and these guys still wanna fight over whether Tux could beat up Microsoft Sam.

AClockworkHellcat
Автор

I think the linux communuty need to own its mistakes. Do not try to hide back doors like a certain commercial operating system.

nomadhgnis
Автор

Been told already by several windows users that linux isnt more secure thanks to the xz situation..

So wrong on so many levels.

incsvpo
Автор

Reflections on Trusting trust is such a gigabrain idea. Insane that they already thought of this happening back in the 80s

hoardingapples