XZ Backdoor is NOT that bad!
HTML-код
- Опубликовано: 30 сен 2024
- Who was affected by the XZ Backdoor? MOST of the Linux community wasn't... Let me explain.
Website Guide: christitus.com... .
►► Digital Downloads ➜ www.cttstore.com
►► Reddit ➜ / christitustech
►► Titus Tech Talk ➜ / titustechtalk
►► Twitch ➜ / christitustech
Key Takeaways:
1. Arch Users were never affected (SSHD isn't linked to Liblzma)
2. Do not expose port 22 (Its bad security practice and ALL Linux servers I've setup never expose this port externally through WAN)
3. This was bad, but lets not pretend that every Linux user was about to get hacked. It was NOT that!
for me key takeaways also include: 08:26~08:31 😂😛
What do you mean don't expose port 22? How would I login to my VPS otherwise?
Most users aren’t using Arch, and even with that it was not as bad precisely because it was on unstable repos/testing. Still highlights how backdoor can still happen😅
@@michaelns9887 In a business environment, it might be required to VPN into the network to gain access to machines with port 22 open, as the firewall should be blocking anything to port 22 from the internet. Local machines on the network can still have 22 exposed to devices on the LAN.
this backdoor was right on time to be included in ubuntu 24.04 and thus affect its massive userbase on the desktop-side and in the server space.
It's the fact that it "could've been" one of the most horrifying backdoors so far. Yes, thanks to that random dude it never went to production.
Yup! It could have destroyed so much, but even still Arch would have never been affected and I kept seeing everyone refer to this as ALL Linux users, when it wasn't the case.
Being that it affected ssh security it would have hit servers the hardest, which I think are mostly Debian or derivatives. It would have been bad. We dodged a bullet.
That one dude? You mean the Microsoft Dev that found it lol.
Now say it will pride "THANK YOU MICROSOFT!"
@@pluto124 Yes, but most businesses and server do NOT expose port 22. So even still it wouldn't be the end of the world. Bad?... absolutely, but would every linux server get hacked? Defintely not.
@@ChrisTitusTechalso only Jia Tan could have exploited the back door, who likely has only one or a few specific targets (it's already limited to deb and rpm distros) and with everyone else with the vulnerability being relatively safe. Even so, Andres Freund is a hero, would have been a nightmare for a lot more people if this has actually gotten to stable versions of majors distros.
It's not so much the impact of this exploit, it's how it made it's way in. It raises the question: are there any other current undetected exploits? If it weren't for this Microsoft guy finding it, then we would be none the wiser. Linux users' main pitch seems to be "muh open source I can't get exploited" and assume that absolutely everything is vetted properly. Don't get me wrong, open-source is still king, it's just that the community and maintainers need to be EXTRA vigilant.
Yeah that is a good take away. I think every operating system has undetected backdoors, but how many? The NSA Backdoor (Blue Ocean Exploit) was the worst I've seen.
I made this video just because I was tired of everyone saying EVERY Linux user was affected. Forgetting some distro weren't and most, if not all, users block external access to SSH.
Realistically, it was found in review and patched the same day. If that isn't a great example of the benefits of open source I don't know what is.
@@nathanl2966ikr
If this guy did not find it someone else would have the next day, its not a miracle. The system works.
Just to add to this if you don't program what's it matter if it's open source if you can't personally audit the code and still have to trust others.
I think the concern is the implication of the potential other unknown vulnerabilities.
That isn't what people are saying though
It's the most practical concern, but that was far from the primary damger highlighted in many videos. They typically go on about how catestrophic this one exploit would have been had it not been spotted.
Easy to be the voice of reason when you are late to the party, hindsight is always 20/20, being that you were late, you probably shouldn't be so smug about it.
You say that like being late is a stroke of luck. Perhaps he intentionally waited until he got his facts straight. Being fast to be wrong is still wrong.
If you want expert commentary, it's often going to be late. I don't just drop everything and start doing research every time there's an attack on an open-source project. Also the expertise you need isn't always from a security specialist. They obviously are faster because they focus on security. You can expect for there to be aspects to security problems that are only analyzed by other technical experts long after the fact.
For example, if you want to know about how to improve the design of test systems to catch attacks targeted against them, you probably want to hear it from a test engineering specialist, not a security specialist. If you want to know about the particulars of how the exploit takes advantage of particular language quirks, you need input from the experts in those specific languages. They aren't always focused on security news either.
@@AvaiLeon still no need to be smug about it if you waited on purpose.
@@Ormaaj even after that novel you wrote, there’s still no need to be smug about it if you’re late to the party.
@@bkrich If someone prioritizes speed over truth, and it turns out they're wrong because they didn't do their due diligence, then being smug is completely justified. Maybe learn to get your facts straight before making a video/article/etc. about it.
how about a video about setting up remote admin without exposure of ssh ?
i wont call him the microsoft engineer
but the XZorcist
Best comment.
@@somegeezer4058 gotta put a disclaimer cus i dint come up with it, i've seen this dadjoke on other videos regarding the subject
I hear you say not to expose SSH. What do you recommend if you do need to access your system remotely? Have you already done a video on it? You have done a ton of content. I may have missed it.
I think most people do it indirectly over IPMI. Although at the end of the day that is also SSH.
I too want to know more about this, I'd assume it's pretty common to expose ssh, I'm not sure what other alternatives are
Allowlist ips that can ssh in? It removes nearly all bruteforcing attempts
Pretty sure best practice is to VPN into the network where port 22 is available on LAN devices, while still blocked at the WAN.
just use a different port, as simple as that.
Yes, no users were exploited because it was only used in unstable builds of certain distros, but had it had gone unnoticed, it would've affected everyone using the main builds of these, including web servers running them, which the most likely target of this attack as so many web servers use linux.
So yes, it is bad, or at the very least, was about to be very bad
Yeah, but those servers still need SSH exposed, which if following proper security practices won't be.
@@ChrisTitusTechSo you never SSH a server externally if you need? What is the point of SSH, then? Newbie question, sorry.
@@goforsteve3042 I think what he’s getting at is that if you’re using a nonstandard port is the likelihood of someone actually getting into you is very small and plus if you’re not using password authentication or just doing keys… Again the likelihood of someone bypassing your security using exploit is also pretty nil… don’t get me wrong. There’s still a possibility but as long as you’re not using 22 and just opening yourself up to being destroyed, you’re more safe than you are exposed.
@@goforsteve3042 SSH is used on LAN and a VPN or other auth is required before you can even attempt to touch a server using SSH. This is how it is done in business.
@@ChrisTitusTech Thanks, I used a putty tunnel before and then a password phrase on the old days… on a freebsd server.
The fact it was detected quickly and someone was able to go through the code and check and find out should be arguments pro open source! Imagine if someone does this on a proprietary software? I mean, the technique used was so so sneaky, I'm pretty sure it could have passed even on proprietary software.
closed source to fix it... they would have to acknowledge they allowed malicious code to be entered and approved... I doubt they would ever fix it until someone found the vulnerability... as fixing it would mean the liability of knowing now they released something bad... and rarely will they accept that.
I agree. I went and read the cve and did my own research and was like “Debian Stable isn’t affected, my servers are good, I don’t have port 22 exposed, so no big deal for me”.
no, no, no. If Fruend would not have accidentally found this we ALL would have a big problem (telecoms ect). So some change in security would be appropriate
"this isn't some YMCA concert" hahahhaha
That killed me when I heard it 😂
Why doesn't Linus have an AI that searches all submissions for the signatures of code that asks for enhanced privileges and send those to trusted developers to verify?
Nobara wasn't affected because it still uses XZ and libzma 5.4.4
Same on Fedora 39, the current stable version.
I wonder how many backdoors are in production. Yes random guy caught this but it feels like this wasn’t the first attempt.
Although not that many people were affected by the backdoor, I think that the most important takeaway from all of this is the broader discussion. Like others have said, what are the chances that exploits like this are out there in other OSS? How do we deal with trust and treatment of the developers of OSS from this point forward?
Funny thing is that I was like "Good thing I didn't switch to Linux yet, would've been bad timing to get breached the same time I got into Linux." then a comment straight up said "Unless you use SSHD or any XZ Utilities tool, it only affects server side; It doesn't affect Desktop users themselves. You would've still been fine". The fact that people exaggerate how bad it for everyone is hilarious, but at least it spread the word out better and the potential implications were more than enough to let everyone know what's going on
It's actually even more limited than that, you'd have to use one of the very few vulnerable unstable Linux distros, and you'd have to be targeted by the one person/party who has the key to use this backdoor. It was found so quickly it was probably never even used.
@@noderunner_ fr tho, it's like the Linux community came together and patched it in a single day if even that
Stable commercial distros (except the weird ones) use older, battle hardedned versions of the software they ship. Unstable and testing branches of those distros run bleeding edge versions and people using them for testing look for odd, undesired behaviour. And when they notice something, they tell the community which can then in turn look into the code (open source and all) and figure out what's wrong. And as I see it, that's more or less what happened here. Working as intended.
I believe the concerns about the danger of the XZ backdoor is not overhyped.
The only reason it's not as critical as it could have been is that it was discovered very early on. Imagine if this backdoor had gone unnoticed for 2-3 years. During that time, the affected package could have made its way into downstream "stable" distributions like Debian 13. That scenario would have been extremely grave, potentially even more severe than the impact of the EternalBlue backdoor.
Cool Manjaro isn't affected then, whew.
manjaro like arch
@@sergebuable It's not
@@ПетрСмирнов-щ2е It's literally an arch-based distro, just like any other arch-based distro. If you want to spread fud about distros at least do it properly.
@@ПетрСмирнов-щ2еManjaro is literally based on arch. They do some weird things that make them a less viable option in my opinion but they still are using Arch as the base.
That's not even the main concern, though. It really doesn't matter if your distro of choice was unaffected for this single exploit that we happened to learn about early on. You should still not expose SSH to the net. Or any other ports, really, that aren't strictly necessary for the services you want to provide. I have a random virtual root server in some random datacenter that I occasionally use just for playing around with server stuff. And whenever I expose SSH to the net (even on a non-standard port) it takes something like an hour until Fail2Ban blocks the first IP Address for trying to bruteforce the password. 22 really is the most often attacked port. If you leave SSH exposed, It's probably just a matter of time until someone actually manages to get in - with our without a big news headline like this one.
Remember, this is also a windows problem because WSL and would be perfect way to hide from windows tooling. Also disabling ssh internally is bad. Also to note the malicious kickstart for windows wouldn’t be seen as malicious as it would only invoke/install a Linux image from ms and make a failed attempt at an ssh to the new image.
Could you explain why should we disable ssh? How do we access the server then?
OMG!! He said, "This is not a YMCA concert!" OH YAZZ!! I almost fell out of my chair, and it's a recliner!! LOL
I needed to see this. High-five for clarifying this.
I think Chris has been drinking at least half a bottle of Whiskey before making this video. Hybris is his middle name. Chris Hybris Titus. He is now in the state of Mr. Knowall, Know everything better than everybody else, even the guy who discovered the backdoor and now Mr. Knowall will bestow us all with his wisdom.
wasn't the backdoor hotfixed in 5.6.1-2? lol You have 5.6.1-3, the version after it was already hotfixed.
On the other hand, Debian stable users never even had the compromised version of that patch to begin with, they're still stuck on 5.4.1 or something, lol.
The fact that Andres found it when he did is the blessing in all of this. It could have turned into something much worse. Also it is the fact we need to be on the lookout for bad actors trying this stuff. This was bad for those factors, even if the amount affected wasn't huge. It is a story with a good ending that shows the importance of looking into stuff if it isn't working right.
my takeaway was and is ..
that this was a pro- active warning from the linux community. knowing the linux community , i assumed it was probably already fixed by the time of press release lol
if this was a fault in WINDOWS i'd assume major infrastructure was about to occur, that would take a week to a month to sort out😄😆😅🤣🙃
SSH port open, fire your IT guy. With such simple logic life should be easy for you.
Overreaction to an exploit that doesn't actually affect most production systems is likely to be worse than the exploit itself.
Homebrew users on Mac should be aware that the brew maintainers have regressed XZ because of this issue, although I'm not exactly sure how the exploit would work on a Mac, given the dependencies of the exploit on systemd-specific patches to opensshd, and nobody sane would enable opensshd on a Mac, given that the Apple-provided OS-based sshd can be enabled via a single click.
All the "this is why I don't use X" stuff is hilarious, given that the value of X in that statement could arguably be any of "linux", "openssh", "ubuntu", "fedora", "systemd", etc. The real lessons, if you need one, from this exploit, are:
a ) Don't use testing/unstable/beta versions of linux distros for anything other than testing. Certainly don't use them on servers reachable via the Internet.
b) If you're a maintainer on an OSS project, be extremely wary of contributors who use bullying and manipulation to take over maintenance from you. They may well be a bad actor.
Ironically I use Debian Testing on my desktops because I thought it would protect me from such things. My logic being Arch rolls out packages faster, so I thought having a vetted delay from the Debian team would help avoid such things. I did have the bad version installed when I checked, but there was an update already available when I first heard the news. I also don't typically use SSH on my desktop machines, so are blocked by the firewall. My servers are running Debian stable, and even there I setup the firewall to allow allow connections from my IP.
How nice of you to follow up the intro with nothing but total misinformation. The reasons not many were impacted came down to a series of completely lucky circumstances. It was pure luck that this was caught early by a person that was not even in a particularly good position to catch it. It was highly lucky that a critical piece of the exploit targeted an uncommon system configuration. There is absolutely no good reason to believe that this couldn't have been massively worse without these pure luck-based factors.
Happily, I don't use systemd. A slightly better executed systemd-based attack would impact almost everyone but me, including all arch users. Oh irony.
True, there was probably too much hype and sensationalism over the XZ Backdoor itself, but that's not the real problem here is it? And there is a real problem. Malicious actors might gain enough respect and trust to embed little covert functions into dependencies over time. We might not know for sure that this isn't a first time... even for "Jia Tan".
There's a reason it's a 10.0
No it's not every Linux distro. Specifically, those who don't drink the Systemd coolaid were of course not affected. But still, it's pretty bad.
Also, the takeaway shouldn't just be "be nice to your OSS maintainers" but also to the OSS maintainers to realize that just because someone wrote a nasty or pushy email doesn't mean that it matters, or that the person is even real. I know it's easy to say "don't let it get to ya" but... you can learn and train this. And "no" is a perfectly legitimate response.
Also, I said it before and I'll say it again: Adding a compile time dependency to systemd via libsystemd is a no-no, and this is the perfect example for why. Of course even if you compromise "just" process 0 itself that's still pretty bad, guess what, these guys went for SSH because it's the biggest door to the castle. And before you link *anything* into a critical process such as sshd, think about whether 1) that's really neccessary and 2) if the people running the project behind the new dependency know what they're talking about. I.e. NOT people who say things like: "I don't understand why user processes can run after user logout", "I didn't break things I only changed the defaults", "Kernel time slewing is good enough", "My project is not a monolith because it's comprised of individual processes".
It's not fine. I think you're missing the whole point of the disclosure and the backdoor.
"Most people" are freaking out about how it made its way into the release.
Your attitude is quite concerning to the security community.
Don't be snarky it is of putting. Not everyone can be PC specialist,, if yes you probably wouldn't have the channel.
Quite true. It was essentially a non-event in terms of consequences, at least as far as we know at this point.
I think it was more of a warning - and possibly made just for that.
Chris: It's not that serious. CVSS score 10 out of 10: Am i a joke to you? Also every distro made an announcement even Arch which you claim is not affected.
"is NOT that bad" what a click bait. You hooked me 😀
The major problem is it's a open source problem. I'm still chocked over it.
I guess I'm more salty than you, I'm still salty about Open Solaris, the Red Hat was just a refreshed load of salt on that wound.
wtf of course it is pretty bad if it made its way unto Debian Stable, it would have been catastrophic.
TL:DR please. Distill this 10 minute video into a sentence please :D
Sorry, does anyone have a link to how NOT to expose ssh outside?
So, what you're saying is, Linux really IS secure!
Plot twist, he is the hacker that why he didn't get infected
your site header being white in dark mode is infuriating
It‘s like rats, if you see one you can bet that there are others.
Can you pls do a further video explaining firewalls and how this could be prevented by blocking port22 and using good practices so this event could never happen in future.
Being that the xz exploit had root access could it not change the firewall rules to enable access?
You, sir, have an evil laugh.
Flash back to Dastardly and Muttley.
But justified in this instance. Great video 👍
ahahahah I love that BIG TITUS format
"This isn't some YMCA concert" lmao
I need some context as to wtf that means?
2:08 in and I already hate this guy, thanks no thanks
Genuinely curious who is saying it is everywhere ? Maybe I’m in echo chamber of Linux enthusiast, I’ve only heard more or less that a handful of bleeding edge distros were impacted
Just basically an I use arch btw video lol
Most focused on the danger of the back door and forgot how quickly it was discovered - The Power Of Open Source
Debian Testing user here. There was a safe replacement for xz 5.6.1 as soon as I read about the exploit on March 29, so I updated my PC straight away. All fixed. I *never* expose ssh on the web.
5.6.1-2 and later is good... on arch so...
So much for depending on open source code review. That would never have found this.
... because the code was inserted as binary, itself decrypted during build, by the make file.
Very, very, very lucky that Andres Freund questioned and dug deep on why a process was slower than it should be ...
Otherwise, over time, this exploit likely would have spread to other builds.
Yes, it was THAT bad. Luck, curiosity and talent found it.
You do realize that Freund only discovered the back door BECAUSE it is open source, right?
@@mensaswede4028 Re-read what I wrote. Pay attention to things like "code review" - since that is _not_ where the exploit was.
Not even once did I hear people say that SSH should be exposed for it to have an effect. Damn... it indeed is exaggerated...
I didn't like this new view, making your whole background as the screen is a better view, according to me.
ouhhh my Kali Nethunter in my phone is 5.4.5 ... i dont use much it but i forget my chroot installation of kali hahah
Isn’t almalinux not RHEL anymore… I’m still mentally lost in CentOS… also if you aren’t in like xz 5.1.x.x versions of this you aren’t affected? So it really isn’t that big of a deal?
You keep focusing on ssh and how this would’ve done nothing if you didn’t expose ports. But doesn’t the fact that he managed to inject malicious code onto the victims computer prove that if this attack had been left unnoticed, he could’ve easily used the same attack method to inject some other malicious code in a future xz update (simply by adding a new binary test file to the repo with another payload hidden inside) adding some other backdoor that does not rely on ssh?
I use ssh to access my VPS , what other way/things I could use to access my server if I can't expose ssh (I use keys and disable password login)
Initial configuration would still require you to expose the port (unless your VPS provider provides a proper local shell). Definitely worth it to set up though, Wireguard is an extremely light-weight VPN solution. Can also go with Tailscale (built atop Wireguard), less configuration hassle and easier to use.
Use iptables to limit ssh access to your specific IP?
@@noderunner_ How are you sopossed to do that when you don't have a static ip
@@KeinNiemand Dynamic DNS
Downplaying this is not a good look, this is guy is just full of himself thinking he can't be hit
I am just being realistic. Lets say I was running Debian unstable with the backdoor... Still wouldn't matter to me. SSH isn't exposed to the outside world, because I follow proper security hygiene.
People are making it seem like the entire world would have been hacked and that isn't the case.
@@ChrisTitusTech That's an unrealistic take. Your attitude is akin to "this exact situation would not have affected me, therfore I am totally safe against any and all attacks!"
That's hardly being logical or "realistic" at all.
@@MaffeyZilog He just said he was safe against THIS attack. I'm sure he knows that there *could* be an attack that affects him, but this isn't it.
Thanks for making this video.
Sick of RUclipsrs you can’t read over sensationalising this.
Anyone who actually uses Linux knew this was limited from the start, not this apocalypse it’s made out to be.
This backdoor acts as a big wake up call regarding the importance of integration testing. The exploit was very subtle and relied upon some integration glue code used by Fedora and Debian to create an indirect linkage between sshd and xz via systemd that doesn't exist in other distros. Integration testing procedures, particularly around anything that can open a listening port on the system, will have to be reviewed in light of this to try to identify other and future attempts at this sort of thing.
Th worse option in cases like is panic, the best course of action is read about the issue for a while before take any action
If one should never expose ssh, then is ssh even good for anything? Genuine question, I don't really understand ssh. But it seems like ssh would be useful for remote management of a headless system, like a server. If not via ssh, how could one manage such a system? 🤔
What does it mean to "expose ssh"?
When I heard about it on other channels, that was the first thing I did was check the Fedora page about it. And as you said Chris, it only affects Fedora 40 and above (which hasn't even been released yet). Maybe not so good if you're using it for testing, but I doubt a lot of users are doing that anyway.
But it does bring up the question of how contributions to code are checked.
I loved watching some of the video of RUclips's making a mountain out of a very small mole hill. Would like to thank Andres Freund for finding this out and keep up the good work and that includes you Chris. Perhaps you could do an updated firewall and setting that people should use or if the one still relevant if so you could put a link to it.
Yes a firewall video is needed. Somehow people mistook this exploit as anyone can log in to Linux systems when no one should be exposing SSH externally and even if this was widespread in a properly secured world very little damage would still be done because no system would accept the SSH request because it wouldn't pass it to the Linux server.
The good work at Microsoft?
Thanks so much for this video. It was a fantastic explanation of the situation and straight to the necessary points.
I would like to add that maintainer burnout is real. This is heart-breaking for the original maintainer, especially the trusting part over some time. That in it of itself is horrifying. This is a wake-up call for the linux community as a whole. We have to have our guards up to prevent this sort of thing from happening again. If someone really wanted to sink this low. this is how that person would go about it. So messed up.
Yes, of course, but putting yourself in that position is an excessively bad decision. Never do that. If you're the author of some open-source software, and that software gets enough traction that you'll need a whole team for maintaining it properly, and funding with it, either you manage to get just that and keep being the official maintainer, or your step down and let heavy users figure out how to maintain it themselves.
Would linux security would be the same as in windows xp if linux would have the same number of users as xp had :D?
It's heartbreaking how much misinformation has been spread about xz. The truth is the backdoor was limited and we as a community should be focusing on lessons learned so this never happens again.
I guess all the people who vehemently don't use systemd are saying "I told you so" right now!
YMCA Concert, Village people. That was bad. LOL...
this reminds me of the open ssh a few years ago that allowed basically any one to gain root on any linux machine.
Im a n00b when it comes to IT etc so can someone explain why a company using ssh would be so bad gou fire the IT guy? What little i do know of ssh i thought it was the "secure" way to remote into a terminal which I thought was a perfectly normal business practice such as remoting into a a headless server.
Im not sure if whats being implied here is ssh=bad in general never use (in which case how do gou solve the issue) or that its the way its used is wrong (in which case what is the right way to use it?)
Edit: to be clear I know lots of possible answers to these questions but i would rather get the answer from someone who knows what they talking about than guess.
My guess wpuld be either 1. You shouldnt expose the port externally over the net and should vpn in pr use some other third parrty to proxy (vm?) into the internal network before using ssh or 2. You can ise ssh but it sjould not be on the defailt port and should have so kany restrictions added (no root etc) that it cant be easily fpund and exploited regardless
My guess it's that it refers to ssh from wan, otherwise I just don't see how it makes any sense.
Well, if you build it from source (as distros should) and not use the release tarballs, you're golden.
5:44 - ok, but did it require you to expose port 22 specifically? Because I have done remote admin of my home PCs, before. My router is set up to switch the ports from 22 to whatever I set it to when I enable remote access. Had to set it to 443 once to bypass a firewall.
But, uh, yeah... I run Gentoo with mostly default profiles. No Systemd. I was never vulnerable to begin with either. The sploit relied, to my understanding, on having systemd, with liblzma support built in, AND one of the two affected versions of xz-utils. Gentoo is usually VERY thorough about their testing. I can appreciate this on a system package level. On user-facing apps like, say, wine... I usually have overrides enabled.
I run debian unstable and had the malicious code installed for one whole day before I heard the news about the infected package. Debian had already upgraded (well downgraded really) the relevant package so I immediately installed the latest version. It would have been difficult to exploit the machine as it is behind a firewall that blocks ssh.
I think the concern is that if this had gone undetected it may have eventually made it into the debian stable release which is used in many data centres. The attack was also not specifically related to debian (though it needs sshd to be called by systemd and not all systems implement ssh connections i this way). It looks like the perpetrator was playing a very long game and was caught at an early stage. My main concern is that he was able to introduce code into the packages without it being possible to examine the source code.
It raises the question whether he was acting in the same way on other packages (it seems not) or whether there are other malicious actors out there that have not yet been caught. I expect an exploit like this cannot be made on any old package, it needs one that will be accessed during an incoming ssh connection, so that means only a limited number of packages are potentially vulnerable.
issue is not that it didnt do damage, but that it could have caused massive damage to linux systems in general.
Say Freund und enter.
yes, I am the same on NixOS.... not worried at all
I knew I could come to this channel and find some sanity!
0:46 YMCA concert and getting backdoored! LOL :D
Nobara isn't affected. It uses Fedora 39.
i would argue it was quite good!
Too busy being a working dad to use home computer so haven't updated packages in months. Take that hackers
Can it be block
Awesome vid sir! ✌
I'm at the first 30 seconds. Are you not affected because you don't use sshd ? Let's see
I think you get off on being contrarian.
The smug self-laughs at his own jokes tell you that much.
@@ObscuraDeCapra lol
xyzmca....lol
Don't let the backdoor hit you in the arse 😂
Future video explaining the Blue Ocean Exploit?
realy ? i was sure you are a lttle bit smart....
Could you please do a video on patch my pc updater for windows ? Would like to hear your toughts on the software that is also free.
PC updater? Just use the default Windows Update.
All those "driver boosters" and "PC updaters" don't necessarily help you.
@@PhilipMarcYT its not doing that, its like installing software from there and updating it. It does not do windows updates.
Arch is pointless because Gentoo exists.