Slashdot Mirror
Malware Threat To GNOME and KDE
commandlinegamer writes "foobar posted on his blog recently about 'How to write a Linux virus in 5 easy steps,' detailing potential malware infection risks in the .desktop file format used by GNOME and KDE. This is not a new threat, and it appears to still be a risk, as discussions in 2006 did not seem to come to any firm conclusion on how to deal with the problem." There's a followup on LWN.
Use Linux... wait, shit. We need a new answer, guys.
Posts not to be taken literally. Almost everything is sarcasm.
It relies on the user downloading saving and running a shell-script. The only trick here is that in this KDE/GNOME form the user does not need explicitly to add execution rights on the file.
Still hardly a virus, more like a gun without a safety switch. It is one step easier for someone to shoot themselves this way.
Interestingly if we wish to reinforce the 'chmod +x' scheme, desktop files should need a +x (or some other non-MIME property) to be treated specially by GNOME and KDE. Might be an idea.
Well, the author here seems to emphasise that that won't help because on a single-user account, your priority is your data. If you lose your system but your data isn't compromised, you lose very little that can't be replaced. If you lose your data but your operating system is functional, you have lost nearly everything of value.
Why do shortcuts need to have the ability to run code?
The shortcut only contains parameters for the path to the application and a list of parameters; it doesn't run any code itself. The problem is that the application can be (e.g.) /usr/bin/perl, and the parameters "-e 'perl code here'". Removing this ability would seriously impact the usefulness of the shortcuts.
The real issue is that the DEs are blindly trusting a non-executable file of unknown source to provide this information. The solution has already been suggested: turn all .desktop files into scripts (via a #! line, which is already valid comment syntax), mark them as executable, and have the DE run them like any other executable file. Non-executable .desktop files which link to applications would be displayed as usual, but would be treated as documents rather than launchers.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
He is not talking about shell scripts at all. The whole point of the article is a .desktop file does not need to be +x to execute it, KDE and Gnome execute commands in it automatically regardless. So all they have to do is save it and click on it.
So we have a long-known, unaddressed vulnerability and easily accessible instructions on writing a Linux virus.
Does this mean Linux is finally "ready for the desktop"?
1 in 4 Maine children in struggle with hunger.
It does make a big difference in clean-up, though. With the malware not being able to get administrative privileges, it can't get into root's environment. That means that you can log in as root and the malware won't get a chance to take over, and then you can safely use all your scanning and clean-up tools without having the malware disable or circumvent them. Contrast this with how thoroughly rootkits can hide on Windows systems.
It's still dangerous, make no mistake. Once the malware's running locally, it can try local exploits to escalate to root access. But there's a lot fewer of those on Linux systems than on Windows, and they're a lot harder to exploit, and anything that doesn't successfully exploit them will be much easier to detect and remove. This is a significant win compared to Windows.
NB: nothing will protect a system from it's owner's stupidity. If the user insists on being willfully stupid, they're in a position to bypass any and all protections on the system. The only protection is to keep them away from the keyboard.
Yeah it's pretty straightforward: if the executable bit is not set then the file is merely *displayed* as a plain text file. If the executable bit is set then it is *run*.
That means you cannot simply save an attachment from a message and run it. You can however display it, which is fine.
Everything works like this except for .desktop files, which because of an oversight, default to *running* on double-click even if not marked executable. Hence the attack vector. It is made nastier by the fact that .desktop files can disguise themselves with a name and icon of their choosing.
-- Ed Avis ed@membled.com
Fast, simple fix for this: make .desktop files scripts. Start them with "#!/usr/bin/false" or something so that if just executed from the command line they don't do anything, just fail. Gnome and KDE expect all entries to start with that and be executable. If they're executable, they act normally. If they aren't executable, the contents or their properties are displayed instead. If they don't start with the hash-bang line, the interface prompts the user for whether they want to display or execute the entry.
A fancy elaboration could register a binary-format handler (similar to the one Wine registers) that would recognize the "[Desktop Entry]" starting the file as a binary format and, if the file was executable, trigger the interface to act on the entry. That could remove the need for the hash-bang first line, but there's some other potential holes I'd have to analyze for impact.
I am dealing with a user at the moment who just isn't that bright. It is not that she is a moron, she just doesn't think. Somethings she does right, she gets her wallpapers through googles image search and uses firefox after my suggestion.
But she also wants animated cursors and finds them and happily installes them. Cursor Mania.
She just doesn't get, yet, that the internet has two kinds of free and that the more something shouts it is free the less likely it is. How do you explain that firefox is free and safe but cursormania is free and not safe?
The problem is not so much that some people are stupid but that they lack a healthy dose of cynasism, they forget to question things. And that is pretty to stupid.
The system can't protect against this unless you want to life in the nanny state. Women are free to go with convicted wife-beaters unless you want the state to decide your partner for you. People can install spyware unless you want the system to decide what you can install.
For some reason people like you want software to do things you would NEVER accept in hardware. Would you really want a powerdrill that constantly checked wether you where drilling in the factory approved substances, at the right angled, under the right conditions? A screwdriver that refuses to be used as a hammer?
At some point users must accept a responsibilty to operate their equipment responsible themselves and accept that if they make mistakes, they are the ones to blaim.
You know what my solution has been to fix 99% of friends requests to fix their windows PC? Re-install. Whipe the crap and sooner or later they either figure out that "mmm once I downloaded those free smiley's my computer starts to act like a piece of crap, maybe these two things are connected" or at least find someone else to help with their crap PC's.
Lets face it, after 30 years I have started to realise that no amount of suggestion is ever going to result in girls actually giving any of the sexual favors they seem to promise when they ask you to fix their laptop.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
When I think of a "virus", well, that's just malicious code, it's something designed to do some form of damage. It's malware-- software that's up to no good. That doesn't describe the delivery method.
I can see how folks want to draw a distinction based on the severity of the exploit (namely the extent of the potential damage to the system and the level of user interaction), but claiming this isn't a real virus is just silly. Maybe a new definition for the more severe sorts of malware is needed.
A lot of people claim it's a PEBKAC problem, but I STRONGLY disagree.
If you expect people to figure out whether a file is safe before "launching/opening" it, then you are expecting people to solve something arguably harder than the "halting problem" (which I hear is very hard, but still easier in comparison since you are given both the description of the program AND the finite input!).
I propose that:
1) Compliant programs be allowed to _request_ what they want to be able to do (by either using a finite and manageable set of standard sandbox templates, or in special cases a custom sandbox template - which can be audited and digitally signed by 3rd parties).
AND THEN
2a) The user be asked whether the request seems reasonable e.g. Fun Screensaver requests "Standard Screen Saver" privileges vs WARNING!! Fun Screensaver is requesting "Full System" privileges!
AND THEN
3) If approved, the operating system then enforces the requested template, so the program can only do whatever possible within the template sandbox.
Do note there's also:
2b) The request is silently approved if the OS has been told to remember the user's prior approval of the program and template (and the alt/whatever key was not held down while launching).
2c) The request is silently approved if the program and requested template is signed by trusted parties (e.g. OS vendor), and the alt/whatever key was not held down while launching.
I have proposed this concept before to Ubuntu and Suse, see:
https://bugs.launchpad.net/ubuntu/+bug/156693
(FWIW I've actually also suggested this to apple).
It'll be hard to implement, but I suspect it's easier than getting "Joe Sixpack" to reliably solve something harder than the "halting problem".
Lastly, much windows malware REQUIRE a brain to participate in order to spread. It's often harder to write malware that does not require a brain to spread. Many here think they're so smart, but would they really know what a devious binary or perl script actually does? Have they ever looked at the Underhanded C entries?
I filed a bug warning of this security problem on March, 2005. Final answer of the developers after taking it to the freedesktop lists: WONTFIX. So, what's the point of reporting bugs?...
The fix is easy, only interpret .desktop files IFF they have the +x bit set (IOW, apply the regular UNIX semantics). It shouldn't take more than a few lines in Gnome and KDE to fix it, and distros can easily modify the scripts to make all the .desktop files +x-