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.
Interesting article. Cliff notes for those who don't read articles: KDE & Gnome desktop icons can contain malicious commands.
The common defense that "well at least linux malware can't get root privileges" isn't much of a defense. For many users, the most sensitive documents they have are owned by themselves.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
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.
I am a bloody fool. I managed to read the article without reading the article. It works.
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.
Sorry, wrong thread, too many tabs.
-
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.
Linux noobs you should be using OpenBSD from a shell.
Don't be so shortsighted. The issue isn't you losing your files. It is that others can obtain your files.
Just because malware doesn't have root privileges doesn't mean it isn't capable of stealing valuable information from you.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
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
The first problem is indeed that a desktop file does not require the executable bit to be executed (from Nautilus) by double-clicking it.
The second problem is that the file content specifies it icon, name and tooltip regardless of the filename of the desktop file.
For example, a very efficient way to fool people could be to disguise the desktop file into one of the default icons of the desktop (Trash, Computer, Home, ...)
For the virus writer the only problem is to get the desktop file to be saved in the Desktop directory.
Humm... Guess what is the default directory of most applications for saving uploaded files? I give you an hint. The name starts by a 'D'.
Even better, it is possible to specify that the Desktop is the HOME. I haven't checked recently but that I remember that this used to be the default in Ubuntu.
My advice is simple: Start gconf-editor and disable the configuration key /apps/nautilus/preferences/show_desktop to get rid of all desktop icons.
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.
Just because malware doesn't have root privileges doesn't mean it isn't capable of stealing valuable information from you.
I sometimes wonder how difficult it would be to obtain the root password from somebody. If the PATH variable has a path that the user has write access to, what's stopping the malware to put a "su" wrapper into that directory? Next time you enter su, the wrapper captures your password, logs you in and deletes itself.
I also think that a keylogger for X11 wouldn't be too difficult to implement.
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-