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.
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.
Which in this case is unlikely to be GNOME or KDE, since this attack has been known for several years and absolutely nothing has been done about it (it's "expected behaviour").
-- Ed Avis ed@membled.com
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
I tried to make it a choice by the end user as to which is less vulnerable. MS products have/had similar issues by length and criticality. So if any and all of your choices can and will have such vulnerabilities, use other criteria for your choice.
On a side note: Worse than having a vulnerability in the code base for several months or years is having it left there intentionally, and marginally worse is when users ignore the patch when it is provided. With Linux patches are free. With Windows products you need to be a legal registered user and/or have paid for updated anti-malware software. Consequently it costs you more to apply fixes for some OSes compared to Linux.
So, in the end it is still down to the user to do their part. No matter what efforts the coders put in, if the user fails the malware will spread.
I'm not apologizing for bugs/problems in Gnome/KDE code. I'm simply saying that such an event only makes it software. When those packages continue to have such errors on a regular schedule and with end effects that MS has tortured the world with, then it's reason to complain.
Support NYCountryLawyer RIAA vs People
I advocate the "Don't run as root." position for two reasons. One, it builds good habits from the start, both for users and for software vendors. It gets users used to running as ordinary users, and conditions them to expect the system to function correctly without administrative privileges except when explicitly doing administrative tasks. We've seen on Windows how many problems keep sticking around simply because of habits users have developed over the years. Inertia works, so put it to good use instead of bad. If you teach users good habits initially, they're likely to stick with them. And it gets software vendors used to living in a world without administrative privileges. When most users expect not to need admin privileges to use software, their reaction to software that expects admin privileges is to go "WTF? Why do you need that again?" and to go with other software if the vendor insists on requiring the user to break their existing habits (users are lazy and don't like changing their ways, remember). That yields a feedback loop: vendors produce software that doesn't require admin privileges because users react badly to stuff that demands admin rights for no good reason, and users react badly to software that demands admin privileges for no good reason because 99% of the software they work with "just works" without admin privileges being needed.
It's also a safety net. If I manage to bork up my user account, root's still sitting there untouched and I can still log in and repair the damage. It's like having a spare set of car keys in your wallet: you won't lock yourself out often, but when you do it's an incredible relief to pull out your wallet and find you don't have to call for help.
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
Remember the Melisa "I Love You" virus that first came out maybe a decade ago?
Ha ha!, I thought, How stupid do you have to be to open a file that is sent to you and all it says is "Hey, look at this picture!".
Certainly, it should be quite suspicious. No comments. No "Hi, how are you.". Plus, the news was already out that you should be very, very careful.
Well, my workplace, which was full of some very talented and bright developers got infected. Our whole network slowed to a crawl as more and more emails were being sent to everyone. I was receiving hundreds of emails each minute. One of our top developers admitted he was the one that caused the infection. He was actually waiting for his friend to send him a file, and when the virus mail came, he clicked on it.
"Using your brain" doesn't always work. I've talked to brilliant developers who found themselves suddenly caught in a phishing scam.
Even I was almost caught. I received a phone message from an 800 number about a problem with my credit card. I called back the 800 number, to find out what the problem was.
The first thing they asked for was my credit card number. My son started screaming at me not to give the number and I relented. We did a Google search and to my surprise, he was right. It was a phishing expedition.
Remember: I wasn't called. I called an 800 number. The person didn't simply answer "Hello", they identified themselves as my credit card issuer without any prompting. If my son didn't stop it, I would have given some stranger who was masquerading as my credit card issuer my credit card number.
The book "The Design of Everyday Things" talks about a software program (pre-Windows) that had the user press the key (sometimes called by the right side of the keyboard on some occasion, and other times, the key by the numeric keypad.
Users were having severe issues. The developers blamed it on the users because the directions clearing distinguished between the two keys. Even the users felt stupid because they felt they should have known better. In the end, a UI designer stepped in and eliminated this distinction between the two keys, and solved the problem.
Sometimes, "Use Your Brain" is simply an excuse to allow bad design to be ignored rather than fixed. If enough users are having difficulties with a certain situation, it isn't enough to castigate them on their lack of intelligence.
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
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 vulnerability is in the way the desktop environment hides information from the user so you have no way (even if you are an experienced and responsible user) to avoid executing the malware. You get an attachment by mail, you just save it to look at it and see what it is (a one-click, and expected-safe operation) but when it appears on the desktop background, it's disguised as something else (the .desktop file can choose any icon and name it wants), and double-clicking to view the file in fact *executes* the code without asking you.
What should happen: you save the file; if you chose to save it to the desktop background it appears there, but because it's not marked executable it will not run when you double-click it. Instead the file contents open in a text editor, or some other fairly boring but safe action.
-- Ed Avis ed@membled.com