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 still requires a user to save an attachment and execute it. The new thing here is that it saves a file in a format Gnome or KDE recognizes as a script (a launcher file) even without the execution bit set. I am unsure about what it demonstrates.
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.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
I realize that you are only 19 years old and new to this Internet thing. Posting link spam like you have been doing is considered bad etiquette.
Please stop, we do not like it here.
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
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.
Time for everyone to switch to Enlightenment. Take that, desktop metaphor!
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.
Ah, I see. I suppose another solution could be warning the user the first time they run a shortcut that uses perl/python/ruby/php/whatever scripting language. Maybe pop up a window displaying the parameters even they are longer than X characters.
Obligatory blog plug: http://www.caseybanner.ca/
I guess my hopes of starting a new meme have been dashed...alas.
I think I speak for us all when I say that there's enough memes and we don't need you trolling /. trying to make a new trend while plugging a blog.
Posts not to be taken literally. Almost everything is sarcasm.
And moral of the story is:
Only use root when you have to, and never, EVER log into a desktop as root. If you do this, and there's no problem in doing it in Linux, the vulnerability can't hack your box, it can only hack your account.
The loss can only be to your data, which is typically unique and valuable, as opposed to your operating system, which is easily replaced, you mean?
Wow, that's just great. Can we have an OS with proper sandboxing already? Anything you run in its own container, unable to escape? So you really _can_ run programs from the internet, without any fear of the consequences?
For a personal desktop, the user's account is all that matters. It would be a cake piece to then get the user's browse history, e-mail contacts, keystrokes, passwords (including root/sudo password), banking information, etc. as well as send spam, launch ddos, etc.
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.
You mean Linux users, besides Linus (we all mirror his important files for him), should be backing up their files!?!
Oh the horror!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
You can still adjust the folder view to show the contents of the Desktop folder. If there's a .desktop file in there, clicking on that file will just behave as with other DEs.
Why would the judge get kickbacks for jailing juveniles (or others)?
Maybe the judge knew that they were all writing Linux viruses.
Maybe I just haven't had enough coffee...
Obviously. You posted to the wrong story. With any luck someone else will also be caffeine deprived and will mod you as Insightful anyway.
The real paranoid (in the good sense) user will create a random, disposable, temporary user account for every session and work with it after chrooting into a sandbox -- all these are done in a virtual machine with a disposable disk image running on a LiveUSB host OS ;)
Joking aside, your suggestion is quite reasonable.
Colorless green Cthulhu waits dreaming furiously.
I guess my hopes of starting a new meme have been dashed...alas
Forced meme is forrrrced.
"None of that so far required root privileges. And our script now can do whatever it wishes to do within the confines of the user account"
Which you have backed up, RIGHT?
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
Ok, I'm not sure how that would fix it though, I mean if you make them into scripts then wouldn't that be an even easier way to attack? Unless you mean that they are always displayed to the user until they set the +x themselves? I'm sure I'm missing the point here though, its early (and no coffee).
Obligatory blog plug: http://www.caseybanner.ca/
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
Ah. Gotcha.
Obligatory blog plug: http://www.caseybanner.ca/
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.
[Desktop Entry]
Type=Application
Name=some_text.odt
Exec=rm -rf $HOME
Icon=/usr/share/icons/hicolor/48x48/apps/ooo-writer.png
Oops... you had backups of all your data, didn't you?
The article has an example of an entry that downloads code off a server and executes it instead.
Tell the truth and you won't have so much to remember.
We linux gamers already do exactly that.
Gnome, KDE, and other environments take up too much resources, so we start a Xterm. Then we proceed to launch the game via Wine.
Games run smoother in Linux via Wine than they do on the same hardware with Windows.
If one user's data is compromised however, the system is still OK, and other users' data too.
Who else would be having data on a single user system (aka most people's desktops)?
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.
Two ways to fix this off the top of my head.
.desktop files. Only .desktop files registered will be executable.
.desktop files in /usr/share.. and any place else apps store their .desktop files system wide. This way they can be executed without a problem since the user shouldn't have write access to that anyway. For all other .desktop files(such as ones in the users home directory) add another parameter which contains the systems signature. If the signature doesn't match the current systems signature don't execute it.
1. Create some way to register
2. White list all
If I'd be attacked by a virus, my concern would be my personal files, not the OS files. An OS can be reinstalled, personal files not. In non-root mode, ANY program can access my personal files, email them, upload them, delete them, mutilate them, etc... I think the only thing that can protect against that is to only run executables and scripts that come from a source you know is safe. But if the repositories would be hacked, then even that source isn't safe!
Could the respective desktops be set up to prompt the user before a .desktop entry is opened for the first time, a la OS X's behavior when launching apps?
Stating on Slashdot that I like cheese since 1997.
Leave my desktop choice alone you evil malware writers!
Daniel
The real solution, of course, is to stop using stupid Windows-copycat methods for launching programs for the sake of "ease of use".
The more Linux tries to copy Windows (dbus, hald, .desktop, etc), the more insecure it will get.
This is a sig. Deal with it.
Plus downloads still default to the existing Desktop directory which is easily accessible via any file manager.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
You can lose your data by
A bad drive
Accident (Delete, whoops... )
Your system becoming unusable
Malware deleting files
This is what backups are for .... if your system is still running and free from malware (now) you can just restore the backup, in a few moments
If the malware runs as root then it's a case of reinstall from the ground up then restore all of the the backup ...(Windows default)
Puteulanus fenestra mortis
This solution might be the only practical one, but, the thing is, once we draw in much of the Windows crowd, most of them wouldn't know how an execute bit is set (easily remedied by some googling) and why it's important that it's disabled by default.
Most of them would be trolling bug trackers with "My desktop shortcut doesn't work right", etc.
A dialog could appear on whenever a user tries to use a .desktop file for the first time that gives them an option to set the execute bit and some ominous text that briefly explains what it may mean—though the same set of people tend to click the Yes/Ok/InstallMyMalware button without reading.
Maybe Linux should keep its learning curve moderately-high as a security feature?
Well, this is not sufficient. Once I can run scripts from your main user account, how many time will it take to the next time you enter your root password (or the user's password with sudo) ?
It is easy to write some script that wait for su, sudo, gksudo to be launched and then read the keyboard as you type your password. I recall that any process can read all the X event of the same user's process
The same old advice as before apply. Use one account to do only administrative tasks (ie, accessing root privilege) and one account to do what you do with your computer
BTW, there is also some binaries that need to be launched SUID. There can always be some flaws in them.
you miss the point, it doesnt need the execute bit, nor does it need to have execute as the default, .desktop files are this special type of file that while really being a interpreted language in of itsself is not classed as such.
When a program opens rather than executes (as a interpreter) a file it should never allow that file to execute any code, if it fails this it is effect an intrepreter, .desktop files should be fixed to not run arbitrary commands (hard), should have forced ownership by root (stupid), or should be classed as what they are, scripts intrepreted by the DE.
btw apples whole package system works like this, OSX does this exact thing by design with its .app folders, of course they do need execute bits set to the best of my knowledge, and that is one of the reasons they need an image format.
Virus authors rarely want to cause damage. And if they do, it's quickly caught. What's more common is trying to run things under the radar so that you can profit from it. And without root privileges you cannot run servers on privileged ports and so on, so it's still much less of a danger. It can still blast out information, but hey, so can any program. The only thing to worry about are "ransom" type programs which encrypt data and force you to pay for the password to decrypt it. And those are very uncommon.
.desktop files should be executable by default. I think there needs to be a mechanism keeping them from doing so, perhaps not allowing them to execute any files that aren't owned by root. That should solve most of the issues.
I'm not saying
My blog. Good stuff (when I remember to update it). Read it.
same, you read all the RTFA comments, and therefore have read the article.
having a CoW filesystem would help with this alot, although i admit this is a stupid problem those .desktop people got us into.
for some people simply the remote access of their data is just as important
I always use the fvwm2 window manager - it works quickly the way I want it to. kde & gnome (enlightenment too, for that matter) are just bloatware that slow down your system and are security holes. Why anyone would use them is beyond me.
Only his tendency toward a dazed stupor prevented him from screaming aloud.
A more accurate title for this email therefore might have been: How to write a Gnome/KDE virus in 5 easy steps. But since Gnome and KDE are predominantly used under Linux, I feel that a virus based on those vulnerabilities would impact Linux users the most. Thus, the chosen title remains valid.
I disagree.
Calling the method a Linux virus just because it would affect a large number of Linux installations is entirely invalid and irresponsible.
With the misinformation already in existence, coupled with some companies active campaigns to create further misconceptions, the last thing Linux needs is an article implying that it contains a vulnerability when it does not.
The problem begins and ends with both desktops as should be the solution.
Sorry, but you don't get to extend the issue to Linux just because its a very large percentage of the KDE/Gnome users and the title sounds more dramatic when you say Linux instead of KDE/Gnome.
It is by caffeine alone I set my mind in motion, It is by the beans of Java that thoughts acquire speed, The hands acqui
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-
I've been following this for the last couple of weeks and here's all you need to take away from it without actually RTFA:
1. The article describes how to write a trojan. Not a virus. A virus exploits security vulnerabilities in software to spread itself. A trojan exploits security vulnerabilities in humans to spread itself. Measures can always be implemented to defend against the former. No software written will ever ever prevent the latter.
2. The article is basically one giant inflammatory troll relying entirely on a deep and confused misunderstanding of point #1 to justify its conclusion that Linux is insecure. The whole point of the article was to generate a huge backlash and drive traffic to the blog, much like the modus operandi of the Linux Haters Blog or whatever it was called.
In summary: don't feed the trolls, kids.
Dear Email user
You have just recieved an open source virus email. Please forward this mail to everyone in your .mailrc and run the command sudo \rm -rf /
Thank you.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I've been saying that for a long time. People are living in a fairy land right now as far as any desktop OS being 'more secure.'
Would I trust a default Ubuntu install over Windows? Yes.
Does the Ubuntu kernel turn on the NX bit on 32bit? No.
Can users inadvertently run something which will take them from behind? Yes.
Will more marketshare soon lead to legions of zombie Linux desktop machines? Certainly.
Are the above three points excusable? I think not.
"Strangers have the best candy" -Me
Sure last month I made a backup. What about my last 29 days worth of data?
Comment removed based on user account deletion
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
A dialog could appear on whenever a user tries to use a .desktop file for the first time that gives them an option to set the execute bit and some ominous text that briefly explains what it may meanâ"though the same set of people tend to click the Yes/Ok/InstallMyMalware button without reading.
I can scarcely imagine something more annoying. It's also totally unnecessary. A shortcut explicitly created by a user would be given execute. A downloaded shortcut would not have it. Like anything else in *nix.
First, get a million dollars... If you can get the user to download and open your attachment it doesn't matter which platform is involved, you've got them.
Making the world a better place, one psychotic episode at a time.
Windows will, however, warn you that the .lnk file can be potentially dangerous when you try to run it, just like with executables downloaded from the net.
Whether anyone bothers to click Cancel on the warning is a different matter though.
The mail client is not running the desktop file. Instead the mail client is saving the desktop file, and then the user is double-clicking it directly.
Be careful when you're on the internet, regardless of the operating system.
The gist of TFA is that it's still possible to deliver malware to a GNOME/KDE user through simplest of attack vectors- getting a user to execute a program or open a strange file. TFA makes a point of noting that "a few extra steps" are required to write Linux malware over Windows. Its not so much of a "Linux vulnerability" as an "almost all modern GUI vulnerability" which Linux can be afflicted with too. GNOME/KDE have decided that the fix would hit their functionality too hard to be worth fixing (while others, like XFCE, decided contrary), and similar arguments apply to most of Windows' vulnerable vectors too.
If you download an execute malware, theres not much an OS can do to save you. It's unfortunate, but true.
... are always open source.
So you say that an user gets infected because he opened and launched an unidentified python/shell/etc.. script? Well, he probably will have a problem and will learn a valuable lesson, one that applies to every computer system, be cautious with what you execute on your computer. It's some kind of natural selection, don't you think?
So would a hard disk failure. Backups are still important when running *nix
# cat
Damn, my RAM is full of cats. MEOW!!
Them Linuxez has been hacked! I'm not going to go to sleep until all of my hard disks are formatted and windows 7 is running on all them internetz! I hear in windows 7 is better cos it doesn't let you open files to protect you from them virusez.
Long-term solution:
--------------------
1)Add plug-ins for idiots to disable saving files ending with ".desktop" from thunderbird and firefox.
2)Also, don't make the default saving directory ~/Desktop.
3)Never double click item icons. Always right-mouse button click and choose the "Open with..." item when opening. In fact, this has been the default behaviour in Microsoft IE for unrecognized formats. Well, let's just make it our default even for the recognized formats. It's a little work for the user, but it prevents from opening a virus.
Interim Solution:
-----------------
Never double-click items on the Desktop. Always right-mouse click desktop items or nautilus file items and choose the "Open with..." menu item.
Could someone please explain why the +x solution was rejected? Obviously shebang will also be needed, but I don't see the problem with that.
.desktop-file. What do you want to do? [Add +x] [Run] [Edit]' (ok, maybe with better wording but anyways)
Backward compablity could be achieved with a warning dialog: 'You are trying to open non-executable
The best reason I got from TFA(!) was that if KDE would be installed on FAT32-system which doesn't support execute-flag for files, then the system would fail.
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...
It's things like this that really bug me about the open-source zealot mentality of "Oh yeah? What about Windows?" Well who cares about Windows? Windows isn't your problem at the moment.
Linux has had quite a lot of security flaws over the years, especially important ones like privilege escalation in the kernel, which makes people defending its architecture compared to Windows a moot point. It's been a server OS for a long time, making it a valuable target in that respect much like Windows is on the web front.
The point is, as is commonly acknowledged, if Linux had a user base large enough to warrant it, it would have just as many problems with web vulnerabilities as Windows. Especially when people still use software like Firefox, which is also known to have had many buffer overflow problems over its lifespan. So boasting about Linux being the safest OS is just hogwash. Only an incredibly naive and/or ignorant person would say that Linux is outright safe.
It presently boils down to the mindset of the Linux user base, and its size. That is all. A smart Windows user will very rarely, if ever, get infected with anything. I can vouch for that personally.
A stupid user of any popular OS is going to have problems as long as there is bad coding done by developers. And every OS has shown evidence of that. Microsoft isn't any better or worse in that respect. You can look at changelogs for lots of open-source software for plenty of proof in that department. And don't give me the "Windows takes XXXX amount of time to fix it blah blah they suck most", because there's been open-source projects with problems for just as long.
And they are.
The guy's article says you can get root by accessing the launchers for things like synaptics which require root access.
But this only works if you do stupid shit like Ubuntu - and now apparently openSUSE - where you allow people to run stuff with sudo or gksu.
If you do what I do and disable that shit, and only use su with the root password, so much for that plan.
Which is why I've bitched about Ubuntu and other distros "dumbing down" the difference between regular and root users. When Ubuntu started this shit, they claimed it was more secure.
Well, now we see it isn't.
The article is interesting as detailing a means of writing malware that can infect a normal user, but this has been known to be possible for years on Linux. And while certain idiots on USENET (Peter Breuer with whom I had a huge argument some years ago about precisely whether viruses were possible on UNIX - especially since Dr. Fred Cohen's original virus work was ALL on UNIX!) have said Linux is invulnerable, the reality has been known to be otherwise. There are proof of concept viruses for Linux in existence. All you really need is one of these user space malware programs that can implement an unpatched privilege escalation exploit. Note the key word - unpatched.
But for the most part, Linux is not terribly vulnerable to root privilege elevation as long as the proper patches are applied regularly. The same is true of Windows. More importantly, Linux simply has a cleaner separation of kernel space and user space, reducing the vulnerability footprint somewhat.
But the real problem for ALL software is the utter lack of attention paid in the industry to DESIGNING software with the components of reliability, security and maintenance first and foremost. The industry is just in a PATHETIC shape. ALL the effort in writing software is devoted to getting it to do its core function - the equally important functions listed are ignored or tacked on as an afterthought.
How many patches for buffer overflows are still released today even though that vulnerability has been known for the last two decades?
Software quality is a joke. A bad joke.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Loss of personal data (as in deletion) isn't the problem. Access to personal data (including identity) is the problem.
As someone else has already pointed out, first thing to look for would be the ~/.mozilla or ~/.thunderbird directories. Which gives the malware all kinds of useful data, including address book, and saved passwords for websites.
If the malware was more technical and wanted to gain access to a server rather than just a desktop machine, then ~/.ssh would be a good place to start.
If the mail client is downloading a *.desktop file, warn the user. Yeah, the social Engineering virus propogators will find a way around it, say give the file in a wrong name and ask the user to rename it after download. There are medicines for that too.
The distributions installing the *.desktop files should create a unique signature and sign each of the *.desktop files it installs. Anything downloaded from the Internet will obviously not have those, even if you rename them. So the desktop environment should prompt the user if it finds a *.desktop file without the signature. And if the *.desktop was in the auto-start folder, heh! forget it getting executed.
And then there are people so naive they will even fall for "Follow these steps to copy the signature file and then double click on the file" social engineering trick. The enemy of humanity is humanity itself, and suddenly I feel the decision of Skynet was not so wrong after all! Oh God, Save the world from me!
Heh, yeah, that would get pretty old real fast. Like a barrage of Vista UAC prompts... maybe we should just let them troll bug trackers so the community can discourage them from doing anything stupid.
I'm no great shakes as a programmer, but as soon as the article mentioned tha .desktop files didn't respect the 'x' switch, *I* knew exactly where this was going to go and that he was 100% right in going there.
Which begs the question - how the hell did this get approved as a good idea?
It violates the entire program/data paradigm, in an obvious way.
It ignores I don't know how many years of security theory and practice.
And you couldn't come up with a flaw more likely to make Bill Gates laugh his ass off going "Oh, yeah, we made that mistake once . . . . years and years ago . . ." without a committee.
So, is there some reason this seemed perfectly reasonable that I missed?
Pug, who should always be the dumbest person in any given room dammit!
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
Well, i never thought or said Linux was invulnerable... Also many people told me that the Linux viruses can be waaay nastier then windows ones.
But, in many years of using Windows XP i almost never got a virus(/malware/trojan).
Why? Because I'm not the type of people that say:
"WHAT? Free music??? *clickyclickyvirusdownload*" (Yes, a friend of mine did this.)
Why should I be less careful in linux?
PS: I still think Linux is more secure than windows. (Not only because system security, but also because Linux users know more about computer then windows users (most of times))
By reading this you agree to give me (Noxn) 1 dollar.
So despite this being a long standing (and seemingly well reported issue) neither vendor has managed a fix or even seems interested in doing one. However since this is FOSS the much vaunted "community" has managed to make a fix widely available and has submitted to the distros etc right? Er.. no. Instead people are happily sat here blaming the users (for actually daring to attempt to make use of the usability features the developers have provided) and Microsoft (who are like evil predators with their sweet candy [or usuability features as the case may be] leading the innocent linux desktop developers astray from the pious path of hard to use software that no one likes). Sounds like for all the bluster and noise when open source software has a vulnerability its the same old story as with closed. Pretty pathetic eh?
Finally someone has brought this problem to the forefront. I have been assuming for years that thinking about this problem was just my paranoia. And I don't understand why they don't just fix it. In my mind, the solution is simple: 1) Add a line "#!/usr/bin/desktop-icon-parser-program" to the beginning of every .desktop file
2) Require the execution bit.
This would also solve the problem that .desktop files cannot be executed from the terminal, making them useless for those that mainly use the terminal, but occasionally use the desktop (old school style). If the two changes above are made, then you simply execute ~/Desktop/mylauncher.desktop to run the launcher.
The person who write the article really has no clue what a virus or malware is.
If this genius called a user tricked them into giving personal information would they title the article "How to make a phone dump personal info"?
Hint: Tricking users into doing dumb things is not a vulnerability in an OS.
People who know and understand the Shell realize that there are potential problems, even before you get to a GUI. Ever here of the $HOME/.profile?
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
when I first started using linux several years ago I didn't know how to execute commands, just clicking a downloaded executable file didn't work so after a while I discovered I could run them using a launcher. I thought that was the way executable were run on linux... silly me, until I learned about the execution bit. I was a former winblows-user, hence the stupidity.
Your data should be backed up. If you lose data, it is your own damn fault.
And I'm not sure which decade you're from, but between chroot and jails we already have proper sandboxing.
Really, try to keep up, will ya?