Malware Threat To GNOME and KDE 348
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.
Frost piss (Score:4, Interesting)
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.
Re:Frost piss (Score:3, Interesting)
Escaping notice is the most important part of keeping malware on system. After it's found, the question is more about how painful it is to get off the system than whether it's going to get removed. Since modern malware authors want their software to stick around in the background for as long as possible, they just avoid doing anything outrageous and let the zombie send out a trickle of emails.
Experience with Windows users shows that the average end user who's willing to click on something like the author was talking about isn't going to get suspicious and won't suspect something two levels deep in a dot folder with an official/cryptic sounding name. They can be brazen and call it 'smtpmmd' for SMTP mass mailer daemon and it'll still probably slip under the radars of at least a few people who know how to look at their active processes. The only real solution is an automated searching tool and at that point you're doing the same thing as all the Windows AV programs, just with a somewhat easier time of it.
Fast fix (Score:5, Interesting)
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.
Re:Linux Users Don't Backup?!? (Score:4, Interesting)
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.
Re:Fast fix (Score:5, Interesting)
Why not just make a proper interpreter for .desktop files, and use that in the first line ("#!/usr/bin/desktop-launcher")? Then the DEs could always run executable files, and always display non-executable files. As a bonus, you could run launchers from the command-line.
Re:Not really news... (Score:3, Interesting)
The "Look! nude pictures of [latest chick seen on a hollywood blockbuster] ! If it doesn't open, save and execute" routine is pretty cross-platform. It relies on the Stupidity 0.99995b RC12 Gold API, and it is here to stay.
Which is wrong and has always been wrong by the way. And it's not "open, save, and double click" not "open, save and execute".
When someone double clicks an icon that signifies it's an image file, that action should not execute an arbitrary command on your system. There needs to be some sort of guarentee that the icon chosen to represent a file actually represents the file. There is no guarentee with .desktop files. This is a bug damn it, not a feature!
And you have a strange definition of "stupidity" which goes something like this: "Not paranoid enough about the interface because it is possible for attachments to deceive the user as to their nature." The interface is broken, that's all there is to it. But it doesn't surprise me that your average GNU/Linux user doesn't think that a broken interface is a problem; obviously we're dealing with the stupid user again who hasn't learned the proper degree of paranoia about what the interface depicts to the user.
PS: Just so you know, I'm a huge free software supporter. The great thing about open development is that bugs, when found, often get fixed, but this mentality falls short of the interface and real usability bugs. People, even advanced GNU/Linux gurus, succumb to usability pitfalls, when you're tired or in a hurry or intoxicated or who knows what. I'm not saying we should prevent the user from doing anything harmful to his system (a common strawman on this forum). But it should be obvious to everyone except for this site that if the icon shows that it's a picture file or a spreadsheet or whatever else, that that is what the interface should be. The RIGHT behavior is that the icon representation must reflect truly what is being represented.
Not PEBKAC (Score:5, Interesting)
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 [launchpad.net]
(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?
Re:Protect your self with encryption (Score:3, Interesting)
The programs responsible for creating .desktop files would set the execute bit automatically, so the change should be more or less invisible. The only case where you'd have a non-executable .desktop file would be if it was saved from a program which does not normally create shortcuts: an e-mail attachment, something downloaded from a web site, etc.
Re:Solution (Score:2, Interesting)
Yes, I do believe it should be safe to *open* any file from any source. If double-clicking a file to open it is unsafe, that needs to be fixed. Look at the security alerts for free software: a large proportion are things like 'a bug in the file decoding might allow an attacker to overwrite the stack by making a specially crafted PNG file'. These are treated as security holes and fixed, because it must be safe to merely *open* and view a PNG file (or whatever) from any source.
The idea that some files are 'bad files' which you should not even open to look at is a screwed-up view of the world that comes from Windows, where the OS and applications don't usually bother to make any distinction between opening and executing. On a sensible system, there is no reason to be afraid of using email and viewing attachments. I have absolutely no fear about saving any attachment from any source and opening it in emacs to view it. The desktop environment can and should provide the same safety.
To continue your analogy: the bug is that currently, with .desktop files, GNOME doesn't give you any way to see what it is apart from putting it in your mouth. Just as with any other kind of file, it should just display the contents for viewing, and not try to taste it unless the file is explicitly marked executable.