XZ Utils Back Door AFTERMATH - Who did it?
Vložit
- čas přidán 2. 04. 2024
- XZ back door hack in Linux was found exploiting SSH with liblzma but was is the aftermath. Linux Distros like Fedora, Red hat, Ubuntu, Debian, Arch Linux were effected only if using bleeding edge software. The hacker for this exploit may have been found..
My Linux Cheat Sheet and 25 Page Checklist here:
📚 learn.savvynik.com
Share this free tool and support Small CZcamsrs
editbulk.com
(I made this tool to help creators)
Want more info/content?
savvynik.com
Useful Commands/Links:
Discord: / discord
Timeline - research.swtch.com/xz-timeline
How Bad? - news.ycombinator.com/item?id=...
RedHat - www.redhat.com/en/blog/urgent...
Debian - lists.debian.org/debian-secur...
#linux #security #pc - Věda a technologie
Andres Freund should never pay for a beer again.
With how much he saved, he shouldn't have to pay for rent or food again lol
Medal of freedom too.
And get FREE mechanical keyboards for LIFE!! LOL
I guess there is so much more in the other libs and not only for Linux… probably this is on propose made and not only from bad actors. They cheating us for decates…
At least learn to pronounce his name?
The long-term planning, infiltration of development personnel, and sophistication of the vulnerability, all convinced me that this was a coordinated effort by an organization rather than the doings of just an individual. I personally feel that this was state-sponsored cyber sabotage.
Individuals can perform long-cons, and have been since time immemorial. It very well could have been state-sponsored, but it also could absolutely have been a single person. I mean, think of just how much you could have sold it for.
@@Squiddy00in this case, it's very unlikely to be a single person, considering the amount of trusted accounts involved in the pressuring of the xz mainteiner to allow more people to be maintainers. Unless this guy can program like 8 times what a normal person can, I doubt it was only him
@@99temporal But those accounts who did the pressuring weren't "trusted", they were pretty new with no real history to their name. Which IMO speaks against a state actor, at least against one being behind it entirely. To me this smells like some genius building the backdoor and then selling it to someone who did a piss poor job of trying to get it included in distributions.
Also I would assume a state actor would have ways to corrupt the single maintainer who already is trusted - either by money or threats.
@@Squiddy00 Yep, a Zero Day that affects all Linux versions, which this would've been once the 5.6.x line started hitting the Stable repos, would've been worth mad cash to the right people. Microsoft engineers saving Linux's ass was NOT on my Bingo Card for 2024...
@@magicmulder "But those accounts who did the pressuring weren't "trusted", they were pretty new with no real history to their name"
In the context of the rest of your comment and this thread, it appears you are arguing that those new accounts are part of a sock puppet operation owned by the "lone genius".
I would argue a state actor or org would also have accounts to show up in the comments section of CZcams to argue it was "only a lone genius".
Hacker: "And I Would Have Gotten Away With It Too, If It Weren't For You Meddling Kids"
Looool
Jia Tan : Drat! Double Drat! [if you remember that TV reference I feel sorry for you]
Be sure to give the meddling kids their Scooby Snack. 🙂
@@musicalneptunian dang....you just dated me
Meddling gits
Some state actors are really angry with Andres Freund right about now.
My bet is on IDF. They are at he bleeding edge of cybersecurity/hacking.
Good.
He is not suicidal.
Pick any three letter acronym north of Mexico for starters......
@@tonywood3660mossad has 6 letters
One variable that is missed here, which is the original maintainer. Had he had not been going through a rough time. He probably would of gone like. "wait a minute, something is not right here" This really goes back to how nasty social engineering can get. Jia Tan exploited the author while he was down. That's just horrifying on itself. The open source community needs to do better of how to handle social engineering attacks. We have failed this author when he was seeking help. very heart-breaking to say the least.
Nah, Even then it would've been harder to spot. It's a really sophisticated way of injecting the binary using tests at build time. Kinda amazing at the same time scary.
It's not that obvious. The most sus thing would be that stupid "Simplify SECURITY.md" commit (what would even be an innocent purpose of it?), and him begging distros to use the new version. Other than that? "Hey the binary files you uploaded are not used in any tests" "Oh right sorry! Fix coming soon!". The true maintainer would have to either make a release themselves or inspect the release by the bad actor, because the code was injected during the building process using a changed makefile. Or maybe ask questions like "how exactly can I make that corrupted test file you added here?" (the bad actor claims it was with random, and the new commit in 5.6.1. changed it to random with known seed, but there is no info how to reproduce it or what the seed was, for obvious reasons). There was also that lockland change but that could've been explained as a typo.
I've heard this a few times now, what exactly is the original maintainer going through?
@@mursie100 Most likely burnouts and possibly personal stuff.
When you are a state-sponsored "hacker" with almost unlimited resources - things can happen
Sure this could have been very bad. But you should see it the other way around. It took them 2 years to set it up and they were wrecked within only 4 weeks of actually compromising the code by some random member of the community. That's the power of open source. And it shows the level of expertise this same community has.
Well it's not the open source community in and of itself. It was a Microsoft employee so does that make it the closed source community?
Don't you find it odd that so much in the world depends on humble free contributions from a few pseudonymous developers worldwide that no one cares about?
Yes
Sadly, no. Seems to pretty well sum up the state of things currently. I certainly WISH all these amazing contributors got more recognition and appreciation!!!
At least we know about this, just think one rouge employee at for example apple or Microsoft doing similar, snarfing away some binary blob for a test or just straight into the src.... Would we ever know? Or if discovered just silently patched out?
They don't. This backdoor only affected a few less stable versions of Linux. It's not like Google and Microsoft were affected. This could have been bad had it gone more long term.
Or worse, who could be blackmailed, abducted, replaced etc. without anyone realizing.
Let's take a minute and empathize with Jia Tan. They spend two years trying to make this work and were so close before they got denied! The world can be so cruel sometimes. /s
Bleeding Edge means you can get cut, i'll stick to my boring LTS. 🙃
Hope the original maintainer of XZ is doing ok, a rough time for them.
I agree.
You do know that this exploit was actually explicitly targeting LTS server distributions. They were incorrect when they stated that Arch was susceptible. In reality those things were explicitly avoided because the attack is aimed as servers (potentially even only specific ones).
This makes sense if you think about it because making a new vulnerability to target either lots of systems (or just statistically most subsets of those systems) you want it to be in the widely used versions of those things. If you use/expose it while it is still just on the super early adopter's systems, you use your chance before it even gets installed on the computer(s) you were trying to target.
In other words, when it comes to purposeful exploits like this, you may actually be safest counterintuitively on bleeding edge because you are less similar to the probable target. If they use it on you they risk being able to use it on the many more people/their intended target, so they normally do what they can to avoid it.
The exploit in question is only included when you are building a Debian or RPM package (you can see that in the code of the exploit script here arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/). Furthermore it is only included in the tarball (i.e. it is not in the actual VC source). Any build that depends on those versions, built for a deb or rpm package, and using the tarball as source is vulnerable (regardless of the label of the build). All this goes to show that they were trying to hide this as much as possible until they can get it pushed out to their target systems.
Packages that are not made as deb or rpm, building it directly from source for personal use, building the package from the VC version (rather than the tarball with the exploit), and older versions without the exploit code and object should be safe from this exploit. If you are running a critical system however be careful using earlier versions as well because while they don't have this exploit there is still a possibility that there is something else in them (albeit pretty small imo).
@@kanoaika hilariously enough there were memory errors from the malicious code misunderstanding structures because there were no checks for the operating system it was running on. Those were caught via valgrind and were super suspicious... especially with the performance usage increase in the ssh liblzma process... I'm glad that Andres Freund looked into it. I don't think someone could have looked into this if it wasn't open source.
@@Entropy67 Yep, with proprietary software when something goes wrong you either just get a new thing to add to the list of things you hate about the software that the devs did, or if you are feeling particularly non-jaded you send an image to their feedback black hole so you can either get a canned response about how much they value your opinion, someone saying "sorry that's not my job", or the bad actor being tipped off and making it harder to detect. So at least you have multiple ways to have nothing get better lol.
Will people please stop referencing SomeOrdinaryGamer as a source for security content? He has borderline knowledge of stuff in this regard and doesn't really understand what he is talking about. Please use better resources for this, such as LowLevelLearning
This needs more upvotes. SOG has some good videos, but security is not one of those topics.
SOG is a infosec communicator, are you daft? Do you think Bill Nye is a real scientist too?!
LLL isn't much different, everyone is an armchair commentator
You can just pay someone to push in a well hidden exploit. Most people have a price.
This reeks of state sponsored shenanigans (including the socio-psychological turmoil, pressure and manipulation Lasse had to go through)
It’s not hard to come to the conclusion that, if left undiscovered, this would have been one of the most severe moments in Cyber Warfare to date.
Just imagine a bad actor getting full control (or even sabotaging/destroying it from the inside) of your country’s energy grid, hospital network, traffic systems and similar paramount infrastructures. The guy who discovered this, and all the researchers who are now actively dealing with this should be labeled as heroes.
We still hsve no idea who the attacker was, the account /username is most likely an alias and probably hides multiple people behind it
Given the name, I would say its most likely a group based out of China
This has no information I didn't get elsewhere. I was really hoping, with the title you chose, that you had new information about who it was.
Go check low level learning new video he just uploaded like some sort of demonstration of how the xzbot worked... Again developed by another Open Source programmer
@@NeverTrust298 - Thanks! That was really interesting and informative. It also gave me an idea/reminded me a principle. :-) The principle of least privilege. ssh needs to be redesigned so the bits that talk to the Internet never run as root.
It is called clickbait
I’m really glad this got caught.
Whoever this was, posing as Jia Tan, he wasn't afraid of Google handing over the details of his Gmail account to the US authorities... the IP addresses he used to access it, history of emails etc.
I would imagine that the US authorities would be asking Google to hand some of this over?
But they used Gmail, knowing that this was a risk.
He uses VPN. One of the IRCs has log of him logging in. It was connecting from a VPN.
What a great way to lay false trails.
Isn't this one of the great things about Open Source? Anyone is able to review and catch issues like this? (Thanks Andres!)
can't say the same thing about closed source....
Although you are correct this does bring up problems with brining in binaries. There should be a HUGE philosophical discussion of even allowing in ANY binaries without MAJOR scrutiny.
Stuff like this wouldn't enter closed source to begin with because there are no anonymous contributors like "Jia Tan", everyone is named, everyone is doxxed, everyone is known and if anyone tried this in closed source they would know that they are looking at life destroying lawsuits as a result.
Yeah, if the maintainer of a closed project even knew about something like this you have to trust they care enough to fix it.
@@mro2352 Remember you're testing a compression library, there's no way to test it properly without known valid compressed binaries to compare against, and you can't rely on compressing them at runtime because then you're not catching bugs when your tool fails to compress them properly.
One potential workaround is to have two versions simultaneously and have a version pulled from main do the "known working" compression that you later use for comparisons when using the staging version.
But it's not as if this was a major oversight on Lasse's part, it does make sense in the context of what they were doing that Jia would push compressed files to the test folder.
@@JoeEnderman We have security audits every month, anything raised there is a critical ticket that must be fixed immediately, releases get blocked by them even yellow and minor issues can block releases.
Benchmarks are baked into the build process, any increase of 100ms let alone 500ms would trigger alerts that would need to be manually reviewed.
Finally if anyone did push a backdoor, we know their names, they signed a contract and are identifiable persons that the company can easily file major lawsuits against. It's not really something closed source needs to worry about.
But for open-source due to the anonymity aspect it's a major problem that definitely warrants some rethinking.
And not only the possibility of malicious contributors but also the lack of motivation to keep thanklessly maintaining projects for free for several years of your life with nothing to show for it.
Should the for-profit Linux distros pay people like Lasse for their work? Should say RedHat commit resources to aid their unpaid dependencies when people like Lasse already verbalised that they're burned out?
Is this a click bait video as the title is "Who did it?" but this video didn't say who did it. Or did the video author want to send the "Who did it?" question to us and was waiting for an answer? If she/he is waiting for an answer, then my answer is "Not me".
Report this video as scam.
This was caught on time but more important how many are in the wild that we don't know off.
For many security people systemd used to be a security breach waiting to happen. It has happened now - and the driving force behind systemd has been hit first, red hat. I am afraid there is more behind systemd than meets the eye.
I have read where people are saying that this XZ back door exploit was created by an individual genius; or by a state-sponsored cyber saboteurs. I am not an expert on these matters, but I don't think anyone should rule out corporate-sponsored saboteurs.
except that's hard to hide and could be jail time. probably a Western gov
So...this only affects the Nightly Builds and not the older Stable Builds and only the XZ v. 5.6.0 and 5.6.1 (CVE-2024-3094) - Correct?
Correct. The closest to being Stable with the exploit was Fedora 40 due to release in a couple of weeks.
@@rezwhapNo, I wouldn't Advise that at all. For Fedora I would strongly Recommend '39' and Not '40', and Not Anything with the Word "Beta" in it - no matter which OS you choose. ALWAYS the one before the Latest, and Update that Version.
@@sjbrockhurst65 Maybe you misunderstood my reply? I wasn’t advising or recommending anything. 🙂
@@rezwhapIf you don't as a Habit, Manually Format your OS Drive(s) - now is a Good Time to do that, then Reinstall 'Fedora 39' in your case - in it's own Partition. Update '39' with whatever Antivirus that comes with, Update that Package and Run it for a Check. Then Rebuild your System.
@@rezwhap(you understand that; it's not just you & me reading all of this, right?)
I run Linux on my desktop (normally) Debian, but FreeBSD on my mail and web servers. I think I won't be changing my strategy.
I would imagine that there are people whose job it is to produce vulnerable code. Not necessarily something that can be seen when looking at the specific change but rather abusing multiple weaknesses introduced over a period of time
I think the fact that there are so many branches and divisions in the linux community, makes it entrinsically a little more resistant to this kind of issue
This also shows the paramount importance of firewall rules for public-facing servers.
Depending on the industry that can be hard, especially if you deal with transferring a lot of files.
Given the way this went down, and without considering the possibility of an earlier version of the backdoor already being present, this entire situation seems like a flash in the pan as far as severity. Sure, its severe in HOW it happened and what WOULD have happened next, but what actually happened? Basically nothing. Linux distro developers and those running nightly builds or bleeding edge releases need to evaluate their exposure. Less than 0.01% of what it could have been.
Fortunately it's an ordinary backdoor and not a flaw created intentionally which can be exploited stealthily. In certain circumstances a loose bolt equals a door.
I was affected, but not effected by it, since I had to investigate at work whether our embedded systems are affected. They were not. Neither were my working or private laptops which run Arch Linux. I have no clue who put the misinformation out there, that Arch Linux was affected by the backdoor. It was not, since the backdoor only installed during the build process of RPM and DEB packages, which Arch does not use.
This could have been so much worse. I can see a lot of code auditing happening.
I think binary files should be banned from critical lib.
How would you propose to store data for test cases for libs that perform work on binary files (libpng, liblzma, zlib, etc.) then?
Edit:
To answer my own question one could propose that the test stage includes a step that downloads the binary test assets (or copies them from a non-repo folder), then the tests run, and finally a step that deletes the binary assets.
Thus the binary test files would never make it into the source control repo.
But depending on the lib this would be a large overhead for testing, both in terms of raw computation time, but m mostly due to the logistics to ensure that everyone who contributes to the project has access to all the test files...
@@danneh1276 Why the fork would I need "test cases" in my production environment? If I get an update for ls or cd, do I get strange binary files along with them to "test"? This stuff belongs on the developers' machines, not on those the finalized software is distributed to.
@@danneh1276 lol it seems i get wrong. Then testing the files many times should be final answer
The binary object that was included is only in the tarball version (bc it would would obviously have been more more visible and suspicious in the actual repo). Building from the VC version completely negates the issue in this case.
Opensuse tumbleweed was affected as well.
Yep, but the rollback came quite fast, so i guess there is no big damage.
now thats how you do backdoors! damn! hope he's not state sponsored ...
1:13 I thought they did it. But it makes sense to deflect at this point.
As Ken Thompson said in his Turing Lecture "On Trusting Trust," revealing a universal generic computer security flaw that always exists including today, "Don't hire people like me."
It was Col Kitchen in the Club with the Mustard
Betteridge's law of headlines hold's true.
10:30 What are you even talking about. It was discovered by a Microsoft engineer who literally had been critical of some of the open source community commits in the past.
kenny metioned
Big bro!!
bro AF
Thanks, spooks.
the 3-letter guys be like:
"they're watching us, act normal"
Are there more hacks like this? Like this specifically? There might be, but I doubt it. There will be more attempts at this exploit though, now that the "great idea" for how to do it is known. And they'll be stealthier than this was. New ways to prevent this kind of exploit will be developed now, but … they haven't been yet. So in the meantime things are gonna be pretty nervous in LinuxLand.
Is there a theory on where Jia is from, and if different, what state is likely to have sponsored this?
The name may be bogus but both Jia and Tan are legit Chinese surnames. I couldn't find either as given names, but I believe given names are much more wide open in Chinese than in western languages typically. Checking for tendencies, spellings, regionalisms, mistakes in their English messages may provide some clues. *EDIT* Some have noticed that one time only they used the full name "Jia Cheong Tan".
I heard that from the times he usually comitted it aligns with them being on a timezone somewhere in Asia and that they used a VPN based out of Singapore, so it's likely it was someone somewhere in Asia (though Jia Tan is more than likely a completely made up fake name), but more than that we'd only know if the VPN dumps their logs and gives us more info
@@andrewdunbar828 This seems like an obvious redherring though. If the NSA or any other world agency wanted to make a backdoor through socially engineering OSS maintainers, an obvious choice of fake names would be those commonly found in your enemy nations; if you get caught at least you can blame and make propaganda out of it. And in the communication archives there was a moment where JiaT75 named themselves as Jia Cheong Tan, and this "Cheong" part was found to be Cantonese while the rest Mandarin, which many have pointed out to be unusual and possibly a hint that it is a made-up name.
@@SXZ-dev thank you for your insights.
@@andrewdunbar828 much appreciated. I will be following this story.
The video description as of now is wrong (Arch Linux is not effected) . The binary object that contained the malicious payload was only included if it is being built for Debian or Redhat (and further is only even present to be included if you build using the tarball; it is not in present in the VC sourse). So yes, lots of distributions with new software versions had the same version number that was compromised, but the exploit was targeted to only deploy on some of those systems.
Thus, while Arch systems (and lots of other bleeding edge or source based non-targeted distros) have the new version, because they were not being compiled for Debian or Redhat systems, the packages don't include this specific piece of malicious code (not saying it is safe from other exploits if there are any as this was a long term attack and the attacker did contribute other stuff so it may still be good to downgrade if you really care about security).
Since when is it OK to inject BINARY files into Linux open SOURCE ?
So, I tried my best to reach out and report that i had been fooled and tricked and ask for help nearly 2+ years ago trying to understand and report what I assume ended up being this and got blocked from every angle. Every time I tried to reach out I just got insulted and blocked because i couldn't make sense of it at the time. Thanks to the microsoft guy for finally making it all make sense to me. Them mfs took me for a ride, and still don't know the damage on my end really. Lol. It seems to progressively unfold into the nightmare I tried explaining 2+ years ago just in different, more confusing words. Lol.
I feel it will be worse in the future when more people switching to Linux, therefore it more worth to spend effort for an attack.
As always the case.
You think nobody's trying to infiltrate Microsoft to get a backdoor into Windows?
@@magicmulder you misunderstood me, I fear this as a (usually) Linux user. The record making market share is still a 1 digit number, but we already have a problem like this. Imagine if the attacking effort is more worthy and the targeted users are less techy!
Not infected because 5.4.1 on MX Linux which is based on Debian stable.
This was low-key ginormous and the average normie has no idea or knowledge of it even happening. I assume nearly all major Linux organizations will start to follow even stronger safety standards. Moreover, if this event doesn't dissuade you from using bleeding edge software/Distros you've gotta be crazy.
tl;dr this only targets servers (it is an sshd exploit; so if you are talking about desktop users it is already completely irrelevant because they are probably not running an ssh server). Further, the exploit is only included in specific conditions (building from the tarball (not VC source), and being built for a package for deb and rpm). In other words this exploit specifically targets rpm and deb which are uses primarily by non-rolling release distros (Ubuntu, Debian, Redhat). Arch in specific which is the only rolling release one he mentioned specifically was not effected by this exploit (it doesn't use deb or rpm).
In other words this was not targeting the rolling release or bleeding edge ones, it was very specifically targeting the top server distros (Redhat and Debian based stuff) while hiding itself and not activating for anyone else (presumably because those people are more likely to catch it and aren't the target they are trying to attack in the first place).
You can see exactly what they target by seeing the source code (explained here) arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
But did you answer the question of who did it?
Is Jia Tan a pseudonym? Likely, it's really popular amongst the open source community. Is their email address used for any other projects? No, according to the SANS Institute.
So, who did it?
So who did it?
So much efforts to create the back door, and no any good use of it? What's going on with hackers? Why no any good hack not discovered for years? Sad to see how hackers degrade nowadays.
Linux Mint LMDE is still using 5.4.1 ...
That 5 seconds of Muta was enough. That clip sums it's all up; He's more annoying than a gaggle of teenage girls.
Both hurt my ears and brain
As far as I understand it the backdoor only seems to affect SSH servers, so unstable Distros being affected shouldn’t be an enormous problem. But still 1 affected user is bad
All Linux computers (well 99%) run SSH servers.
@@FrankabluBut not all of those computers were on the effected Versions. Mostly Rolling Releases were effected and as far as it is known only Distros that patch openssh to use systemd with liblzma were effected.
There is still the possibility that there are more Backdoors in other versions of xz but this is all we know for now.
We were lucky that the backdoor was discovered in March instead of May, where Ubuntu LTS 24.4 comes out. That being said, Jia Tan has been a long time maintainer (through social engineering) for xz, so I still wont trust any code he writes in the package tbh.
Turns out this rule I set a few years ago served me well: unless you have a very good reason otherwise, disable sshd on your personal linux computers
@@Frankablu But the server needs to run for the exploit to work, so the OSs that would be most likely affected, which are mostly running on Desktops don’t have that problem since SSH is disabled by default and or not accessible due to a hardware firewall (router)
My Klipper Host has faulted due to this lost all of my data! My config files, all of my gcodes...
2 years == money= state actor.
...can you say stuxnet
I wonder how this will be prevented going forward. What kind of signing mechanisms will be introduced, you think?
Well one way to prevent an attack this way, is for Distros to not use the release Tarball but rather the build of Git Repo itself. That way no code can be hidden in the Tarball. But i doubt that the Distros will do this, as it is a little more work than just straight up using the Release Tarball
@@Jan-ux7ht Did you miss the part where the upstream repo was compromised? You know, since Jia Tan had maintainer permissions?
@@vihannes3No I did not. But as far as I understand THIS specific compromise (correct me if I am wrong) there were artifacts in the upstream repo. But they did not do anything without the extra code in the Tarball. So using the repo directly in this case would have avoided distributing the code that activated the backdoor. I am not saying this is a solution for the maintainer problem. That is a whole other story wich we can't do much about, except be careful about who is choosen as a Co-Maintainer.
TLDR We can't do much about these things, but using the repo directly would take away the possibility of hiding code in the release Tarball.
Github requires a mobile phone number now. Why do not just call the guy and ask why?
ngl its made me a bit paranoid lol
The core of this issue is -- 'know your developer' -- My understanding is that the previous maintainer was shoved aside without any background check on the usurper. That will need to change.
The other core is support your developers. The only reason they got access was because the maintainer of the code was feeling overwhelmed (potentially because they also had other accounts that were making rude demanding comments) and they didn't have any good people to turn to for help and support.
We need to be more supportive for these people so that when the pressure comes they have a willing and capable community supporting them instead of a manipulative attacker.
@@kanoaika Indeed. There are several apps I used regularly and I make yearly donations. Just the right thing to do. Would be nice if there was a payment system to do so at a single point. A GoFundMe for devs.
Despite the seriousness of the compromise and the efforts that went into its making what system of any value have a public exposed port 22 today? I am thinking they had a plan to use this for a purpose given the efforts made there must be value systems that are actually exposing ssh to public access, *This* makes me very concerned..
ssh doesn't need to be directly exposed, they might have access to private networks via other breaches.
@@artembaguinski9946 that’s true but once inside a private network there is so many other ways to gain access to machines. The fact it’s an upstream attack on the repo for infecting the many makes me doubt they were just hoping it would get into a few compromised networks.
port 22 can be used for file transfer... using things like sftp-server. The alternatives are all worse.
This feels like the attack was supposed to target a large number of badly configured servers, not necessarily your secure IBM intranet or government network.
@@petersilva037 sftp is through sshd not something you would expose publicly for everyone to reach.
My question to the community is how does the kernel team make the project an even harder target against bad guys?
As a basic Linux everyday user+, the lesson I'm gleaning from this malicious act is, as Linux gains in popularity amongst individuals (4% globally now?), the more the malicious actors (state or non state) will be on the rise. I do understand that the servers are the coveted targets, not so much the desktop users. Although... things can start at the desktop level, right?
Yes, Linux has a fantastic and huge community of individuals that are quick to spot and notify, or even offer fixes to anything that comes up, however... complacency kills.
Again, I'm just a basic user with an observation and a question.
The Linux Foundation, and Linus himself, is increasingly sponsored by China. The biggest commits to the Linux Kernel are from China. The question isn't if there are backdoors, but how many there are. This was likely a US state sponsored backdoor to counter the Chinese backdoors into Linux, which are discovered every few years. As a dektop Linux user, you are just collateral damage.
Are people who aren’t tech savy still behind monitors like the 90s when those in support centres have advice out the arzez their heads were stuck up? A multi levelled monitoring setup was needed long ago when this first pop up on the radar to catch the culprits. You know hackers, they panic the minute one gets caught and sing like a canary. Here’s one tier, you know the hackers don’t have the exploit on the system, sooooooo , WTFshould they be looking for?
Doesn't this just go to show how easy it is to insert backdoors into Linux? All you need to do is find some obscure system with only 1 person maintaining it, then pay them off to insert your code.
At least you can see when it changes. With proprietary stuff you can do the same thing all behind the closed doors of a company instead of in a mailing list or VC/issue tracker.
You can't stop attackers from trying, so at least you should make it harder to hide when they do.
This is such big news because is is so interesting and crazy. This was caught and exposed precisely because it is open. If xz or sshd had been closed source it would have been much more likely to get out into the wild.
@@kanoaikaHas there ever been an actor inside Windows or Apple who inserted malicious code in the OS?
@@hoagie911 1. xz and sshd are not the equivalent of Windows or Apple (iOS/Mac products). xz is a compression utility, and the ssh servers that this vulerability targets are things that would be 3rd party often in Apple and Microsoft systems. Of course there are things like that that have been compromised. In GNU/Linux systems the OS is the Linux kernel and the GNU utils ontop of that. xz and ssh stuff are widely used, but not part of the OS per se.
2. Yes of course if you are just talking about malicious code. If you are talking about backdoors and vulnerabilities, it is harder to know obviously because they are closed companies in the first place (i.e. how can you tell if the vulnerability in such by default intrusive systems is an intentional backdoor, a mistake, or basically just them remote controlling your system (which imo is technically a backdoor even if they have reasons--you can't see the source and the meetings and interactions are behind closed doors).
3. They can force updates (i.e. remotely change and run code on your machine) already so they fundamentally don't need a sneaky backdoor to do whatever they want. If we continue the analogy they don't need a backdoor for most of the junk they do because they already own your house, control everything in it, and have the keys to your front door. For example Windows will gather your data and use it for advertising and Apple will try to force users to install stuff from their store where they get 30% revenue. They don't need a backdoor to do this garbage because they control everything already.
4. Yes, there are accusations and cases where they have demonstrated effective backdoors when asked to by governments and companies (DRM, disk encryption key escrow (i.e. they store the key to unencrypt your disk if you do it with built in stuff and can give it to people if they want)). For many use cases lots of their features are effectively malware. All the stuff dealing with the Government (which both have accusations of) seems true in practice as the vulnerabilities remain, but they will never say (if it true they probably are under duress to not say by the people who asked for the backdoors).
5. This whole discussion is somewhat missing the point. ALL computers are vunerable and ALL software of any substantial size will have vunerabilities in it. Security potential for a given system generally comes down to freedom and knowledge. Security is about only having your computer be able to do things you expect it to do and making everything else hard. If you are using a closed system you are leaving all of that up to whoever controls it down the line. The reason open software can be more secure is because it doesn't restrict your freedom or knowledge. People who make, use, audit, or deploy it can investigate it more easily and if something bad for them or others is going on they can fix it, report it, switch to something that deals with it better, or take any sutible action they need to protect themselves and their usage. Microsoft and Apple do ok at preventing 3rd party threats (as do most established projects) but they are ultimatly in control and you just have to trust that what they are doing is what you want. For some things it is, and others it isn't. They are ultimatly trying to make money, and when that doesn't align with what you need they won't hesitate to ignore and break things for you.
tl;dr rest assured that everything you do on a Microsoft or Apple computer is completely at their mercy and they can do whatever they want. They have done bad things in the past and will continue to exploit their users whenever it is convenient because they build everything so that they can--it makes more money that way. The default state of most proprietary software is the same as compromised for more open stuff.
Over all though it comes down to the fact that the key factor in the power of a vunerability is if your target (or the developers of the target system) know about it. If they know about it they can maybe react to stop it. Open software will outperform closed software in this case (when other things are equal) because it is more transparent. If your trying to sneak a vulnerability into something and get it out to lots of people so you can use it, the fewer people watching what you are doing the better.
@@kanoaikaEverything you've said corresponds with the de jour philosophy in cryptology, so it makes sense.That's how we've ended up with AES after all.
"Who did it?"😕
me who using dropbear
😮
Jia would be a Chinese name and thus pronounced like "Jah" and not "Jeeyaa".
Personally I pronounce it more like "scuzzbag", but that's just me.
@@spudhead169I know what you mean, but I have some friends named Jia and they're cool and not state actors or looking to cause billions of dollars in damage.
@@robertluong3024 Ah okay, well I'll reserve that pronunciation for that single individual then.
TA
and there corporates feed of free linux they should pay
Year of the linux desktop. Finally interesting enough for some one to make exploits targeted at foss desktop. /S
It is targeted at servers. The exploit is focused on compromising sshd. Of course technical users may run sshd on a desktop (I personally do because it is convenient for me), but it isn't something that is going to be running by default on desktop installations, and its main use case is logging in to remotely manage servers.
This particular exploit and probably most technical exploits are aimed at business and servers. Desktop exploits are simply less interesting and less nessecary (i.e. if you are going after random non-tech savy people its often higher ROI to do something easy like make a malicious website/ad and basically run scams or make malware and stuff that attacks the person directly instead of bothering with a system exploit).
It is even more clear when you see that they only include the malicious binary object when it is being built for a package for deb and rpm (the packages used by the most common server distros).
@@kanoaika Bro too stupid for sarcasmn
It's scary to realize that how many vulnerabilities are out there in open source....systems
very few, actually. This one didn't make it to market.
Looks like Muta did it, look at his face, absolute villainy.
Zero new information. Misleading title. => Downvote, "Don't recommend channel", bye.
"Could it be worse"
🤔 How? It just exposed how weak some elements of the Open Source community is... and that's literally what keeps Linux alive!
And as much as we love to say a bunch o people looking at the "code" keep it secure doesn't seem to be the case here.
It shows the strength of open source. Suppose such a backdoor was present in windows server. How would you find it?
this is partially the fault of distro's as they use tar blobs not git pulls, a procedure change is needed for this type of problem to go away
This is easily one of the best coding feats in Linux coding. Makes me glad I'm not switching to Linux yet, but it also means even the smallest backdoors can catch any programmer's eye and can be easily reported to the maintainers of XZ Utils
Just because it was found on a Linux utility doesn’t mean that there aren’t similar exploits in Windows and OSX. You just can’t investigate it as it’s closed source.
What are you using? :D are you sure your OS doesn't have backdoors?
@@captainsalami2113Only Warp OS/2 is safe. /S
Yeah I bet Mossad already has backdoors in Windows, Android and iOS. Good luck finding the ones that are closed source.
Imagine a spy gets hired by Microsoft or google who have massive head counts. And they commit code like this behind closed doors it can be years until someone notices
Honestly, this backdoor/attack doesn't make me fear XZ. If anything, it awakened me to the problem of SystemD, an already controversial suite of applications due to its overreaching into virtually every aspect of a Linux system, being far from just an init system.
It has been made even worse by the fact that it has seemingly become a monoculture among Linux distros, making the combination, IMO, about as bad as the monocultures that are Windows and Mac. The potential disaster that could have unfolded if this was not caught before it had the chance for liftoff only proves it.
Personally, I'm having second thoughts on systemd, and I may consider distributions that avoid it in the future to stay out of this target that is the new Linux/systemd monoculture. Maybe those anti-systemd guys were actually on to something after all. I can imagine the laughs they're all having at the rest of the Linux world now, as they use Devuan, Artix, the BSDs, etc. Joke's on us, eh?
The more I think of this, the more I think the news stories should not necessarily focus on xz-utils--but instead SystemD and the potentially dangerous, sprawling monoculture that it creates alongside the Linux kernel on a machine.
Consider TempleOS. 100% guarantee to not being a target.
Just peeps creating more unnecessary tech drama. Cybersecurity is an illusion. There are plenty of backdoor/barndoor exploits in Windows and Mac OS. This is truly the spirit of open source where anyone can discover exploits with audits like this and track down bad actors. 😅
@@mk72v2oqSorry, I'm not religious, therefore FreeDOS would be more of an option for me. In fact, it's the only one between the two still actively supported and receiving updates.
@@UltraZelda64 until Terry returns.
While the exploit took advantage of systemd patched OpenSSH, systemd is still not to blame at all for this incident, neither OpenSSH.
I think distributions should be more careful how they compile projects and link projects, for a example introducing a compile flag for object files:
(It probably have to be added first in GCC and Clang)
-fcompiler-signature -fwarn-if-compiler-signature-mismatch
If they introduce something like this: BLOB files would have a different signature than the distribution compiler, and would cause the compiler to warn or error and let the distribution see they linked a BLOB unwillingly into a project.
They obviously could now maintain many different object files for different distributions, but it's much harder to maintain and it would caught much easier.
Another thing: If it wasn't systemd patched OpenSSH, they would focused on a different project, they would found a way without systemd.
About anti-systemd: The same people: "There too many Linux distributions, every Linux is different it's bad".
People really don't know what they want, i think systemd is a blessing in having a easier time configuring Linux systems over the recent years.
And now appears that iBus tarballs don't match the git repository.
Oh, well. Time to start to migrate to reproducible builds.
Don't panic, Zstd is better anyway.
I often wonder about that question. So many youtubers think it is important to educate people about Hacking. Maybe they are hackers, maybe one of the viewers are tempted. In my opinion, "ethical hacking" or "hacking to protect yourself", is very very popular on social media and I can tell you, if I was 17 today, I would feel tempted to do some damage and earn some easy money. Fortunately I was in my thirties when I got my first Commodore 64 in 1988.
Yes, it is NOT the end of the world as we know it.
Yes. We can affirm beyond any shadow of a doubt that there never has been, there isn't, and there never will be a problem in Linux. This proves that Linux is invincible, if anything, and people should carry on as if nothing happened...
@@NapsterBaaaad What's your point? I'm guessing it's pretty ignorant.
@@indiesigi7807 I’m sarcastically ridiculing the sentiment some seem to have, of “nothing to see here…” because it was found. This is a pretty serious issue, that highlights a real problem with open source… and some are choosing to act like that fact it was found means there is no problem, that one can be sure if there were any other such problems they’d obviously have been found, and the old “imagine other OSes and how much worse they are!”
@@NapsterBaaaad I don't see the connection. I think you're using this opportunity to shit on something barely related you don't like for some reason.
The author from this hack will be found.
I don't believe that, specially if this was state sponsored.
@@videocommenter235 will be found
I like how all sort of idiots with mustaches talk about things that they don't fully understand.
Would be great if you could finish a sentence without pausing in the middle for 3 seconds.
My favourite part is the government writing a report on their own linux backdoor exploit pretending that they weren't the guys that wrote it 😂
I guess all of the Steam Decks are affected.
No they run a special version of arch that’s not bleeding edge release. Should be good
@@SavvyNikAnother reason not to run bleeding edge Arch.
@@vogonp4287Arch wasn't affected at all, the backdoor was not activated.
@@vogonp4287 Arch's SSH/Systemd or whatever was specifically not dependant on XZ/liblzma, but they still warned their users to update to a less compromised version of xz anyway.
@@daniel29263 Yes, but the rapid update pace in Arch means that future exploits snuck into packages could actually reach in use systems before they are found. Stable distributions like Debian, RH, Ubuntu, etc, have more time to deal with them.
CLICKBAIT
The reason youtube bloggers are hyperventilating over this is because they want views, and drama brings in the views.
This was a bit of a lame attack, I'm sure there are a lot of more sophisticated ones out in the wild. We should have compiler and hardware level protection against attacks. Stricter rules for building could also help eg.: no binaries in git, or the build tool must be trusted, no funny business patching libraries with binaries. It can be done. The amount of work that goes into fixing CVEs is ridiculous.
The binary wasn't in the git. The binary was included in the tarball and set to only be included in the build under certain conditions to hide it on the systems they weren't targeting.
Imo the biggest takeaway should be with the social engineering side. Maintainers should see how these guys manipulate the situation to gain access by taking and not tolerate people who are going to demand things rudely from the dev. The community should learn that we need to be there to support and defend the maintainers when people like this are out there. They only got access because they pressured and abused the dev while simultaneously playing the part of a 'helpful contributor who just wants needs a bit more access to help relieve the burden.' We need the community to be there to help maintain, or find help for the maintainer and to stand up for the dev if they have abusive people who might be trying to wear out or manipulate the maintainer.
@@kanoaikaThx for all the info.
Imagine allowing a chinese dev to push into your project? Dude, at this point this is just to be expected.
It's so obvious that the guy was chinese that I doubt it was the Chinese state but a western three letter agency or a cybercriminal group obfuscating their identity.
It was probably an attempt to see how much you can get away with without raising red flags.
Unknown Chinese sounding name replaces a secure function call with an insecure one and it gets OK'd? Well OK then, looks like the floodgates are wide open!
The government did it!
I say it was either China or Russia. Maybe also some other supervillain country. Guess it weren't the Glowies for once.
Why not?
@@hxllside Intel Management Engine, the AMD equivalent, easy court permits..... don't know, man. This sounds more like something that is useful for industrial espionage. Moreover I'm sure that the 3-letter-bois have enough "assets" in higher management of IBM etc. so manipulating some maintainer seems to be quite the desperate approach.
And paired with the catastrophic market situation in China it seems oddly fitting.
But of course this is just my opinion. Feel free to tell us your own.
Chinese sock puppets usually use names like "john williamson". I think we can exclude china/taiwan out of this. The time of where JT is active also doesnt seem to be GMT +8.
china!
Dear Americans, please learn to use the Metric System ... and to pronounce 'z' correctly.
Maintainer got social engineered by a script kiddie! 😂
that was no script kiddie
Not that funny man. Maintainer had mental health issues.
Not a script kiddie at all, this was a pro, or multiple pros.
@@123dweaver Glad you pointed that out: it is now transphobic misogynistic antisemitism to acknowledge the hack at all. The Science is settled.
you'll get merc'd by a 22lr kid the next time you go to a shooting range.