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.
wait i only vaugely RTFA, but didn't kde 4 do away with desktop icons entirely? now you have folder views, which won't invoke any .desktop launcher file
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.
wtf would an encrypted tunnel do to mitigate the issues mentioned in the article? Nothing.
Fucking link spammer. That's at least the 3rd time you've posted this shit today.
This will not work on Ubuntu 8.04 at least. I have just tried sending myself a shell script that was marked executable, and after saving it, double-clicking it would display it. Even without the extension, double-clicking would only display it. But even assuming that somehow this script was automatically marked to execute, what happens? You get asked a question:
What is the authors method of spreading this? An email with the following in it:
Now, would you want to 'Display' nude shots or 'Run' nude shots? I'm sure you could manage this if you sent something like, "Check out this cool script!" or "Check out this cool screensaver." but the former is already a lost battle (we know you can never protect against a user) and the latter isn't a problem (Linux users do not install from emails, they install from repositories).
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.
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.
Time for everyone to switch to Enlightenment. Take that, desktop metaphor!
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/
You're missing everything.
1) They make money because it's a private detention center which gets state money to house juveniles.
2) There were two judges.
3) You posted this under the wrong article.
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.
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
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.
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"
Not a virus. GTFO.
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.
The thing about Slashdot memes is that they get really tired after a while. I'm not sure you'd want your name on something as annoying and repetitve as a Slashdot meme.
Oh, wait, I nearly forgot:
Alas, in Soviet Russia, new memes dash YOU!
Nah, you don't speak for me.
[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.
This exploit is nothing new. Microsoft Windows has suffered this same vulnerability for ages with its shortcut (.lnk) files.
The Microsoft solution was to configure the Microsoft Outlook email program to identify and block access to .lnk attachments, among many others. It is non trivial for end users to circumvent this restriction in Outlook.
While that's fine and dandy, it does not prevent a user from downloading and saving a .lnk from some other email program or even a webmail interface. For this reason, email aware Windows antivirus programs typically look for and block executables including .lnk files.
If this starts being effectively exploited the the Linux desktop will join Windows in its requirement of A/V software. But, I still expect the real danger to Linux to come from an Adobe Flash based vector.
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
Fixing this should be a top priority for the Gnome and KDE developers so we can keep GNU/Linux malware free. Just make it require +x for launchers and automatically ask the user for the password when running one, to make it +x - kind of like OS X does with sudo operations.
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.
cant we just change this behavior and have launchers also require executable permissions
from now on?
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.
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?
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
... we're all doomed!
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.
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?
My ~/.config/autostart seems to only contain _disabled_ launchers. When I enable something in System>Preferences>Sessions it is removed from that directory, and returns when I disable it again.
But it's really a moot point, since Ubuntu's default cron daemon understands "@reboot". You can get your script going without even having to wait for your infected user to log in.
Presumably you could even watch the process list for gksu or one of the privileged apps to be run, and then run your root payload before the authentication expires.
I agree that root is a red herring, though. All the important data (documents, downloads, etc.) are still owned by the user and can thus be targeted by `rm` or ransomware.
Linux has been pwn3d for years, we're just waiting for an attack to get into the wild.
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.
It's trivial to put up a small script (even directly executeable one, zips preserve permissions) that messes things up. For any system.
So why dont we have any viruses or malware. Becuase of the package system. Everything is tested by trusted people. I dont think you'd have a big virus problem in windows if it weren't for the fact that people usually hunt the web for bullshit software they blindly trust, willingly clicking on anything from anywhere.
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!
If you're lazy? Just boot from an Ubuntu CD and run everything in RAM. Reboot as paranoia requires you to do so, or just periodically.
Running an installed system? Ever heard of jails?
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
"It's funny how the definition seems to have changed."
The first virii I ever encountered distributed _themselves_ by covert installation in boot sectors of harddisks and/or floppy disks(!). The beast, as it is described in tfa, needs manual interaction of the user. And thus it is a trojan.
"When I think of a "virus", well, that's just malicious code"
Then google or wiki for the right definitions, because it is not as if this is still an open discussion. The nomenclature for malware is (by IT standards) old and settled.
Mind you, I'm not trying to make this all sound less serious. I'm just pointing out that your "just malicious code" argument is flawed.
I have a panel across the top of the screen, keep all my shortcuts there, and all of them have been edited by me (with nano, not the properties dialog) to change up the icons.
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.
hey, update your journal!
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.
I wonder if this "security flaw" has anything to do with KDE 4 no longer having a single desktop folder (ie now you can folder view any folder and display it's contents on your "desktop").
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.
If so, do you want to share your wife's files? Your kids files? Your work account files?
Root can do that.
You can't.
Actually I fully understood what you're proposing.
"The request is silently approved if the program and requested template is signed by trusted parties"
I also think that it would be counter-productive to add this as a feature into Ubuntu. Hacking a nag and release and/or a certificate scheme into an operating system that is built on the foundation of openness and quick and incremental changes is a bad idea.
You're talking about approval certificates for many different applications with new builds being released on a regular basis.
The point is... why add the overhead of this module that has to filter all applications on launch and store/query approved certificates when the launcher module just needs one or a couple properties and boolean tests to check them.
IMHO, the easiest fix is to do what the author stated. Add execute permission control to the launchers.
Sorry to be harsh in my last response... Whitelist security schemes and nags just tend to remind me of Microsoft's kludged "security fixes" and the effort I've put into removing them.