Until last week, you could pwn KDE Linux desktop with a USB stick A recently resolved flaw in the KDE Linux desktop environment meant that files held on a USB stick could be executed as soon as they were plugged into a vulnerable device. The security howler created a means to execute arbitrary code on KDE by simply naming a pendrive VFAT volume $() or similar, as explained in this advisory ( …
The Freedesktop people churn out "Open Source" software. It's available as source, but so incredibly complex that only they can maintain it. Since it's very fashionable to work for "Open Source" projects and they rarely deny people working on it, many beginners write code for them, resulting in even more code which only increases the dependence on some sort of "Open Source company" as well as the more or less occasional stupid bug.
"Free Software" only is truely free when the software is simple enough to be understood by a single person or a very small group of them.
"Free Software" only is truely free when the software is simple enough to be understood by a single person or a very small group of them.
Any software simple enough to be competently maintained by a single person is probably insufficiently complex to handle all the tasks handled by a modern desktop environment. Even Stallman himself would not apply such an incredibly limited definition to "free software" as that.
Besides, understanding any open source project is simply a matter of time spent studying the code. There is no such thing as a project so complex that a competent programmer can't understand the code if (s)he spends enough time studying it.
Absolutely agreed. Software is like the medical profession : beyond the common cold, you need a specialist to get a reliable diagnostic.
Creating an OS is not making a fart app for a mobile phone. Even making games has become a very complex undertaking, what with the predictive network code, world mapping and multiplayer handling, not to mention graphics and object interaction (with or without physics involved). There is no way a single human being can assimilate the particularities of each domain in what is commonly called a triple-A title.
You want code that a single person can understand ? Go for the 2D platformers in Early Access on Steam. That is likely to not be too complicated to understand because a lot of them are written by a small group of people. But if you get the code to Call of Duty, I'll wager you'll never get through it all.
So don't knock Open Source on such arguments. That simply doesn't hold up to reality.
"Any software simple enough to be competently maintained by a single person is probably insufficiently complex to handle all the tasks handled by a modern desktop environment."
Actually that's what people thought before UNIX, too. What's lacking is simply the right way to tackle the problem. Imagine instead of Wayland and X11 we would have chosen something simpler, like a virtual file system (Plan9 like) or perhaps a graphics and sound extension to the terminal.
There are features you write explicitly, and there are features that get created by having some orthogonal features which implicitly create a whole new range of features.
It's bad enough auto-mounting by default, but running scripts/executables automatically too!? (if i've got what's actually happening right ...)
This just adds to my general unease (i could just be being a paranoid old fart perhaps) that the standard of software engineering in the Linux world is slowly dropping
Its not running scripts, just a basic injection attack. The script to auto-mount is taking the volume label concatenating it into a string, then running that string as a command in a shell. I presume its searching against a flat-file that maps the volume label to other parameters like mount point, permissions, etc. that get fed into the mount command.
Since it is running arbitrary code, you -could- tell it to run a script, but it doesn't have to be.
mount -L LABEL /mnt/point/
if LABEL = $(touch b), the command being executed would be:
mount -L $(touch b) /mnt/point/
$(touch b) gets evaluated first (being in brackets), that creates a file 'b' and returns nothing, the command being executed then becomes: mount -L /mnt/point
That should give you the idea. There is probably more to it, the mount command would fail if that were it, so they're probably passing another source param (likely the device) too.
I imagine that it is searching a text file to see if it has seen that volume before so it can use user settings versus defaults. Probably so users can set permission-bit-masks, mount options, etc
They author probably just took a script they already had, expecting that someone would replace it alter, but since it functioned correctly, no one bothered to look at the code to see what it was actually doing. Fairly common problem in under-resourced software projects: Someone sets up a script or something as a placeholder for the real code they intend to write; deadline approaches, so code is forced to be shipped without replacing the script; developer ends up working on bugs and other issues and either forgets about the script or just remains busy with fixing broken items versus correcting working code.
"It's bad enough auto-mounting by default"
Well it's just box clear/tick in System Settings to enable/disable automount. There are finer grained options as well if you do want to automount something.
What I can't remember because I always have it turned off is what the default setting for a fresh install is.
It looks nice but quite a lot of things under the hood are giving off the the feel that they have been designed by a not-yet-fully-matured-and-skilled team.
In particular, kmail spooked the hell out of me. Watch what happens when you blow away the akonadi database. kmail will start sending e-mail to whomever: https://forum.kde.org/viewtopic.php?f=215&t=124498 - this being due to akondi rebuilding itself with completely random identifiers that are no longer in sync with kmail. Great stuff.
From my experience, the KDE team is primarily one-off developers that aren't dedicated to the project itself, but are avid users of KDE, so they'll scribble up a code patch, submit it, and it ends up in the tree. Since their code works well enough, the core developers end up ignoring the edge-case bugs and instead focus on the highly-visible bugs or working on features.
Not saying that it is only the KDE project that suffers from this, its becoming quite prevalent across pretty much all software projects, both Open and closed.
For web servers, one of the big security problems for quite a few years has been SQL injection attacks. We solved those quickly, right? Right? Anyone?
So, for Unix-based boxes, script injection attacks will be solved just as quickly. Sigh.
Both work the same way - stuff that should not be trusted is blindly stuffed into command strings, and the command strings are then parsed and run with whatever privileges they "need". Its just plain a bad idea.
Do Windows servers have similar problems, or does Microsoft shipping huge binary blobs actually help with this?
Um, looking at my Windows 7 install, that effing Autoplay is still there - even with all the options turned off.
So no, stuff like this is not thoroughly tested just because MSFT.
Generally, though, I have to agree that because Windows is still everywhere for the moment, whatever goes wrong on it is generally found pretty quickly. As for problems being corrected, that will depend on whether or not Microsoft decides to declare that it is a feature.
So no, stuff like this is not thoroughly tested just because MSFT.
True, it is more thoroughly tested because Windows runs on 88% of desktop/laptop PCs and is therefore the primary target for most security researchers and hackers. As I said, it's about the numbers, not the vendor or ideological purity.
Personally, I find Linux far easier to compromise cf. Windows precisely because it is FOSS. I recently modified and rebuilt SSH to log the passwords attackers use against my servers. I could have made it do anything of course, including building in a hard-coded back door. Much harder to do that with a closed source OS. Now you, being intimately familiar with GNU/Linux source code, might notice that I had done that - but would your average user? I doubt it.
autoplay isn't autorun btw. This attack couldn't work via Windows autoplay functions. If you know different, I'm sure the NSA will be in touch with a suitable cheque ;)
Windows is therefore more thoroughly tested and stuff like this gets found faster.
And that's why you can't infect Windows machines with malicious flash drives, right? I mean never mind that the malicious flash drive left lying around for a curious user to plug into their machines has been and remains one of the most easily exploited attack vectors for close to 20 years, it must not work because these sorts of vulnerabilities get found faster in Windows, right?
Hating MSFT and evangelising FOSS can't change the maths.
No, it can't. And the maths clearly show that hating on ANY modern OS on the grounds of security is silly. They can ALL be locked down tighter than the NSA's sphincter (and, also, any place that's serious about security would absolutely disable the ability for normal users to mount flash drives at all for the very reason I mentioned above).
So this is yet another case of lazy or inexperienced programmers using system() or exec() or some similar function without dealing with special characters in the input first. These vulnerabilities aren't entirely unlike SQL injection vulnerabilities. It's an easy fix (just remove or escape the special characters before passing the string off to system(), as basic a concept as cleansing inputs), but the fact that the fix is needed at all makes me wonder what other massive security holes lie awaiting discovery in that particular code base.
For system calls, exec passes the argument list directly, it's system that executes through the shell. But yes, going by other comments, essentially an injection/escaping attack, quite similar to "shellshock". I'd no idea stuff in KDE was doing system type calls, probably calls for a code review.
Many, many years ago I used KDE. I liked it. One day, after an upgrade, it started playing a little login jingle (just like Windows). The only way I could find to turn the jingle off (I didn't look very hard) was to switch to Gnome. Gnome looked a lot better than it had the last time I compared the two, so I stopped using KDE. I figured KDE had lost the plot.
I tried KDE again a year or two back, just to see what it was like. It had gone for the "phone interface" style, with almost everything hidden away behind magical hot spots that you had to try to find. That lasted just long enough for me to find the magic logout hotspot. KDE had definitely lost the plot.
Gnome also eventually lost the plot, but I find Mate to be an adequate replacement.
What is wrong with these people?
This is the problem. KDE, GNOME and friends change too often. Even with their annoyances the MS Windows and MacOS shells are useable and I won’t spend ages working out how to do something like say create a desktop shortcut. So I’d much rather keep UNIX family OSs (not just Linux) for servers where they rule and have something useable to live with.
Should be obvious. If you want security remove or disable USB and that was the case before recent Intel AMT discoveries. If you want USB for keyboard and mouse GLUE THEM IN PLACE.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
