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.
Everyone is trying to mimic the brain-dead M$ Way.
Just think of the idea. You click on the icon (who knows what the picture would suggest) and the file path is passed to an "interpreter" (be it oowriter, emacs or python or ld.so) you may not know. This is a terrible idea to begin with.
That's why I use file managers almost only for bulk copying / moving. And I still prefer the CLI if the file names are regular-ish enough.
Colorless green Cthulhu waits dreaming furiously.
Linux noobs you should be using OpenBSD from a shell.
That would require a blacklist of script interpreters, which could only be a temporary solution. No blacklist is ever going to cover all possible attack vectors. Similarly, checking for particular parameter length will either have too many false positives or fail to catch potential attacks. E.g., what if the command was /bin/rm and the parameters were "-rf /"?
Requiring the executable bit would make for a more permanent solution to the problem.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
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.
It is the equivalent of downloading a Picture.jpg.bat that deletes *.* from windows. Windows hides the extension (.bat) so it would be easy to double click on it and bam no more files. Yes the icon would look different.
I have previews turned on in Gnome so I can actually see the picture before I run the code.
Half of writing history is hiding the truth.
Nah, you don't speak for me.
Data theft is much more nefarious and dangerous than data destruction and usually the primary goal of anyone attempting to exploit a system. Backups are great, but using personal data for financial gain is the name of the game nowadays.
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.
On second thought, you don't even need that. The malware just has to do
echo "alias su=/tmp/evilwrapperscript" >> ~/.bashrc
and you're finished
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.
True. Though just as the first case can be prevented by mounting /home (or possibly /home/) noexec, this once can be prevented by doing same with /tmp
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
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-
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
To wit, in a file called blah.desktop:
Which would then open the door to other types of scripts being embedded within the .desktop file, such as Python or Perl (the latter of which is probably the even more widespread of the two!)
This method has a few benefits over the described one, including: offline execution of malware, no further download beyond the .desktop required; semi-easy modification of the embedded script (you can add or remove lines as you wish and even leave comments in thanks to the tail and sed commands used); and the embedded file could easily make the .desktop file it's contained in reach file size levels (something I, personally, look at with certain files) roughly equivalent to the file it's attempting to masquerade as. Theoretically, so long as you remembered to escape things properly, you could possibly even include binaries within the .desktop file in this manner(!!!!).
This of course comes no closer to the holy grail that is root, but still an interesting twist on the same process...