The Story Behind the XZ Backdoor and KDE Unsafe Themes
Вставка
- Опубліковано 7 кві 2024
- 💸💸 Help me contribute to KDE and do these videos: 💸💸
Paypal: paypal.me/niccolove
Patreon: / niccolove
Liberapay: liberapay.com/niccolove
Ko-Fi: ko-fi.com/niccolove
Stay in the loop: t.me/veggeroblog
My website is nicco.love and if you want to contact me, my telegram handle is [at] veggero.
Honestly, there's no reason for a global theme and widgets to have free reign over a system. Any code they run should be sandboxed and have tight restrictions on what it's allowed to do.
Or even better, theme should not contain any code.
At the VERY most, it should be a strict API to allow a tiny subset of OS-level operations in a sandboxed environment.
@@merthyr1831I agree
Considering a person needs sudo permissions to install sddm themes, the person is lucky it was just their home folder.
lol true. imagine if it was ACTUALLY malicious too
On windows and mac, the back door would not have been found without an insider data leak
Exactly. Who knows how many backdoors happened there and no one knew anything
BIG respect for admitting and CLARIFYING when you were wrong! I guess your beard is not long enough. xD
Thank you and all KDE devs for letting me run a system I am very pleased with. ❤
This has been happening for a while in the npm world. Unfortunately, open source has to realize it's long past the days when these projects are just a few small hobbyists and we can't just keep auto-trusting that open source = automatically safe and trustworthy. Core libraries and components are going to have to start being much more rigorously tested and reviewed before they're just pulled in and used. Particularly if they're smaller and less actively maintained.
As geopolitical tensions around the world rise, I think we might see more attacks on open-source software as it doesn't require a real identity or presence to work for it, and the potential of infecting some random library, maintained by a single person, which is used in healthcare, military and financial environments around the world is very tempting. Such jobs could easily be sponsored by governments.
Possibly create a very specific and narrow definition of what executable elements in themes must be written like and what is and isn't allowed. Then use a bot to scan uploaded theme components that have an executable element - any suspicious ones could be flagged for review by a human. Warning messages are completely useless in the KDE store - how many people have the programming acumen to know what to look for and there is no way on earth people will go through all that to check every theming component. An alternative would be for KDE to make a GUI application that would make it extremely EASY for people to make their own themes- including animated splash and login screens. This application should be for the absolute novice and have LOTS of tool tips and hand-holding.
Thank you for all you do Nico
one crucial thing missed from timeline is that jia tan also disabled the gnu IFUNC in one of google's repo too.
It is actually quite the endorsement of the open source methodology that they had to sneak the back door in through pre-compiled binaries. They didn't think it would be safe for their backdoor to be at all visible in the main code base.
While they obviously chose to do it through pre-compiled binaries, that doesn't necessarily mean they *had* to. There have been plenty of bugs that have made it through code review in even well maintained projects open source that took years to discover - heartbleed comes to mind. Using binaries certainly reduced the chance it would get discovered quickly and makes it more difficult to see/understand exactly what's being done, but it's entirely possible they could have instead chosen to craft a "bug" in a different project and had it go unnoticed.
It's similarly tempting to say "this sophisticated attack was discovered rather quickly" and extrapolate that to suggest all such attacks are/will be discovered quickly.
@@masaufuku1735 Yeah true, just because somebody exploits a security vulnerability doesn't mean you're overall secure in places that weren't the vulnerability.
That's why it's important to support and contribute to projects one is using. I'm trying to do both, but my skills aren't good enough yet to do much.
Ricing your desktop can crash your computer...what? (Sarcasm intended). I honestly made minimal changes to my KDE desktop. Dark mode, the Altai wallpaper and the floating bottom panel. Simple and elegant. It's better to create things or do worthwhile things with your desktop than obsess over how it looks. I honestly, spent more time customizing my hotkeys when I switched from Pop!_OS about a month ago. Gotta get that work flow in order.
Governments would like you to conform to a certain standard so their spyware is guaranteed to work. It's be a shame if they have done all this work, and someone decides they don't want systemd, or maybe they want it but they don't wanna add xz to anything. Yeah, without prior knowledge at all - this can happen. Or maybe your system is such that it does have the spyware but somehow it doesn't work. They don't like this, they like predictability. Themes is not something they would target, unless they are petty govs. Most "advanced" govs like the US, would target cpus and firmware and stuff that are completely out of knowledge of others, or out of reach, due to secrecy and hidden specs. Lesser "capable" govs like EU major countries, or eastern countries would target software in "clever" ways, like the recent xz cve, and small pathetic petty govs would browse the haxor forums to find ready made spyware that targets themselves mostly without their knowledge and they would pay money to get hacked - they could use themes too if desperate, or spam, or sms spam etc. Obviously you noticed the quotations on certain words, as what they think they gain short term, they lose in spades long term, and it also removes them from the right to even utter any policies for privacy - hypocrisy is hypocrisy, it's always evident and it never works. You can't be a murderer and condemn murders or trying to convince others. Not even fools would believe you. And you can't be a petty criminal trying to fight serial killers. You are going to get fucked - guaranteed. Wanna fight crime? You can't be a criminal at all. Don't believe me? Try your best flamethrower when you fight a forest fire, see how far you get.
Linux N00B here with a question:
Wouldnt it be possible to put specifically the rm rf command behind a ln additional password prompt with a warning 'Hey, you are about to remove your whole filesystem with this command, please enter your password to continue.'
9:46 finally the shape getting the proper name it should have. no pumping organs involved here lol.
You're on to good start dealing with problem. For know what you suggested can help but it's not long term solution but it is something for start. Idea for plasma 6 stuff having separate part of store than using it to gain time to review everything that gets uploaded seems good and dooable. I hope you folks find long term and permanent solution to the problem in meanwhile users can help by testing global themes on virtual machines and see what happens and they can report if theme is safe or not assuming they'd like to help.
11:20 from where r u reading thi timeline? i have skimmed through both woikipedia's article for xz utils, and xz util backdoor, but this timeline ;s in neither
23:40 "organized crooks" what a funny way to say government ;)
...or corporations quoted in NASDAQ...
All those measures around theming is only a substitution and temporary solution. Why won't you add theming API to Plasma, and thus excluding every code from theming? I know it will take time to write API, but that would fix all issues. However, I understand that any API changes would break certain themes or functionality, but this happens once in a while anyway. API should be a very robust and working backwards as well, so this is another component to maintain, but the new measures will take time and effort too, and they will never cover all cases.
Are there any reasons why theming API would be not a viable solution?
Slowly we are seeing how unsustainable this whole house of cards is. I think we are approaching a turning point. Seems like recently there has been a big uproar about how little huge corporations do for open source. So many projects have changed licenses recently as well.
Very few people actually care to contribute their time, effort and $$$ for Linux unfortunately. I made a couple of donations to Linux Mint back when I was using it. Later I bought a Tuxedo laptop. We gotta support the Linux people who support us.
I'm having a lot of crashes with the in-built KDE theme store after the update to version 6. I use EndeavourOS BTW. I just want to use Layan theme and papirus icons. Nothing else.
Lucky for me im a happy breeze user, so i was not affected with the global theme thing. Although, i would like the dark theme to be more dark, for example darker shade of gray or something.. and not sure if you can make folders different colors like accents on a theme, didn't test that..
A very simple question: is Linux tailored for server or desktop systems?
The name I gave a suggested replacement for "Global Theme" was "Scripted Styler" basically throwing away the "Global" requirment of the styler and directly addressing the inclusion of scripts. I think "theme" should only be used on stylers that don't use scripts at all.
not sure if it's just me but background music is too loud, good music but I would prefer a bit lower volume :)
Don’t go running to Microsoft, and Apple, you know how they are. Linux is the way to go, don’t fall for it. The Penguin breaks windows, and crushes apples 😊 . . . It’s shattered glass, and apple sauce talk
I think it is wrong to take the global theme problem that occurred as a reason to treat all QML logic as "dangerous".
The problem was caused by a shell script that was poorly written and I do think that shell scripts have no place in a theme - the only reason they exist is that installing themes and widgets is complicated and not well understood and themers have taken to collect bunches of "known to work" scripts - that they don't understand - and pass them around, often making small modifications (again, without understanding the whole) thereby degrading the original work further. I think this issue is easy to solve - define a clear standard for how things get installed, let the developer customise the things they need by creating a manifest, and have KDE audited code manage the actual moving things around - nominally what kpackage was supposed to do.
What else is dangerous:
1. Customisations that run compiled code in so files - these are easy to detect during installation, before they get a chance to run, by gsns or kpackage, and we can show a warning to the user allowing them to cancel the installation.
2. QML code calling a built-in functionality that is know to allow non-sandboxed code to execute - such as the "execute command" component - you can detect these with simple static analysis, also during install, and warn.
Everything else should be safe: the QML code does not have file system access and at worst can mess up your plasma config through the kconfig APIs - which I would consider "safe".
A certain feature is potentially dangerous for the users.
KDE developers:
Let's inform the users better, let's provide more options for handling their system in a safer, more informed way, let's even consider spending some time inspecting theme code.
Windows, MacOS, GNOME:
Let's remove the feature.
And that's why I love KDE.
xz wasn't really that bad in the end - It targeted distros that are designed to be incredibly stable and slow to update, so unless you ran debian sid you probably never even had the malicious binary on their system, and if they did it likely wouldnt have worked (if you used nixOS for example).
As for the theming -- They need to be fixed. Whilst this was the "first time" (allegedly), KDE has give a massive attack surface through the store which is largely not human-curated, and even if it was they're less tested by design.
Theming systems should not run arbitrary code! Theming systems should not NEED to run arbitrary code! SDDM themes shouldn't need to run arbitrary code!
Follow the rules:
1) Comment your code so others can understand what it does.
2) Don't use code if you don't understand what it does.
you haven't slept have you? your eyes are all red. could be the lighting tho
I always thought linux being secure was a meme but to my surprise people actually believe linux is secure.
secure is a huge word, nothing is secure unless you properly secure it and then even the best security is not immune. it's like saying a specific car or medication is safe. people need to start thinking deeper about the true meaning of words, especially when applied to systems with so many open/moving parts and variables.
No OS in this word is 100% secure. However, it’s up to how fast / efficiently the _developers behind it_ patch any security issue. Take the XZ Linux security issue for example. Imagine if Linux had been owned and worked on by some big corporation instead. They would have taken their own time, delayed it, and have patched it like almost a month or at least a few weeks later, which would be a security nightmare for the time being. But fortunately since Linux is open source, the XZ vulnerability was spotted and fixed really quickly.
🤦🏻♂️ People don’t believe everything you hear on the web, that goes back to the dial up days. Windows, and IOS isn’t free almost every Linux distribution is, and some of them are way more powerful operating systems.
So tell me then what operating system is actually secure and I shall judge whether it's true or just a MEME
@@PixelRyzl There is no such thing is a secure operating system. Not even qubes or an os that runs on a removable drive can save your ass if you do stupid things online.
thx kde team: my nixos/plasma6.0.3/wayland/rtx3060 runs flawless !
rm -rf "$CREDIBILITY/"*