How to write a Linux virus in 5 easy steps
When you save an email attachment under Linux, the execute flag is normally NOT set and thus, the file can't be executed just by clicking on it. So, no luck? Not so fast. Modern desktop environments, such as Gnome and KDE, conveniently offer a nice 'workaround' called 'launchers'. Those are small files that describe how something should be started. Just a few lines that specify the name, the icon that should be displayed and the actual command to execute. Conveniently, the syntax of those launcher files is the same for Gnome and KDE. And those launchers don't have to have any execute permissions set on them!" Your editor can't resist pointing out that this problem was covered here back in 2006. (Thanks to David Skoll).
Posted Feb 11, 2009 17:29 UTC (Wed)
by rvfh (guest, #31018)
[Link] (47 responses)
I am confused. What happened in more than two years?
Posted Feb 11, 2009 18:25 UTC (Wed)
by drag (guest, #31333)
[Link] (36 responses)
Sort of like how when you setup a python or php website you have the initial file executable, but all the stuff that it reads and uses in the program does not have to be executable.
It's still a problem, of course.
The _Linux_system_ is relative secure, but as far as user accounts on the desktop there isn't much protections.
Posted Feb 11, 2009 18:43 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
So that files that are downloaded to the desktop are automatically given a 'untrusted' or 'internet' security context and it would require a extra step to make them trusted. This is how Vista and Windows XP SP2+ works.
Or use a LSM to make it normally impossible for people to save files from processes that connect to the internet in any directory but the designated "$HOME/Downloads" directory. And then nautilus and whatever will treat those files in a different manner.
That way if Firefox or Adobe Flash gets hacked then a attacker can't modify or otherwise screw around with any other files on the user's desktop.
Sort of like how files stored in the ~/.Trash directory are treated differently then files that are stored in other directories.
Posted Feb 11, 2009 19:42 UTC (Wed)
by mjthayer (guest, #39183)
[Link]
Posted Feb 11, 2009 20:35 UTC (Wed)
by nix (subscriber, #2304)
[Link] (23 responses)
#!/usr/bin/desktop-interpreter
That would fix all these problems. Executable permission is now required,
Posted Feb 11, 2009 21:25 UTC (Wed)
by drag (guest, #31333)
[Link] (20 responses)
When you have code running and connecting to the internet and then acting/interpreting on that data, much of which is coming from anonymous sources that is essentially running with full 'root' rights to anything and everything in a user's home directory then your going to have problems.
There remains a need to have a way to divide a user account between programs that are dealing with untrusted data and then stuff that has full privileges.
As it stands right now one security flaw in Firefox or your Jabber client or anything else (like Evince reading in PDF files you just downloaded) that is going out and fetching data from the internet and your entire account is compromised. There is no need to get root as the most important stuff is running with user privileges and is in your home directory.
Posted Feb 12, 2009 10:51 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (19 responses)
I mean, right now we have the ability to add and remove permissions from a file, but in the "interpreter" case, if the user has permission to read a script file, and permission to run the interpreter...well, how would we mark such a file to say "this is not yet trusted"? Extended attributes of some kind?
Posted Feb 12, 2009 12:55 UTC (Thu)
by nix (subscriber, #2304)
[Link] (16 responses)
Posted Feb 12, 2009 14:08 UTC (Thu)
by hppnq (guest, #14462)
[Link] (2 responses)
So the problem remains the same: do you trust your desktop launcher or not? The traditional Unix security model can never be trusted in this respect.
I would think that it may even be more safe to have an external interpreter run the desktop launcher, because at least you then cannot accidentally run any Joe Random Hacker's setuid binary instead of an easy to parse script.
Posted Feb 12, 2009 20:47 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Feb 13, 2009 9:57 UTC (Fri)
by hppnq (guest, #14462)
[Link]
It might even add a risk if the launcher can also be seen from another environment, such as a shell, instead of being a file that can only be meaningfully interpreted by the DE proper.
All this has little or nothing to do with the ability to run files in a certain way, but with the level of trust given to a class of files.
Posted Feb 12, 2009 14:24 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (10 responses)
Posted Feb 12, 2009 20:49 UTC (Thu)
by nix (subscriber, #2304)
[Link] (9 responses)
Posted Feb 12, 2009 21:11 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (8 responses)
Posted Feb 12, 2009 22:11 UTC (Thu)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Feb 12, 2009 22:16 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (6 responses)
So you would propose that the desktop environments include a ".desktop interpreter" whose job it would be to check for executable privilege on the .desktop files? That could work.
Posted Feb 12, 2009 23:29 UTC (Thu)
by nix (subscriber, #2304)
[Link] (5 responses)
I don't see any reason why anything else in the DE needs to know how to
Posted Feb 13, 2009 1:02 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link] (4 responses)
Y'know, this could work! Gonna write it yourself?
Posted Feb 13, 2009 9:04 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
(... actually, not all that useless: it could be useful from the command
Posted Feb 13, 2009 16:29 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link] (2 responses)
Posted Feb 13, 2009 17:03 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Just having the interpreter return a return code without actually running anything seems profoundly counterintuitive. (Imagine if Perl scripts just returned 1 or 0 when you ran them, indicating whether 'perl $SCRIPTNAME' should be allowed to work!)
Posted Feb 13, 2009 17:06 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link]
Either way, though, I can see something like that being useful in any number of contexts. I can't help but think "If you write it, they will come."
Write the program, audit it carefully, release it under a permissive license, and push for the major desktop environments to start using it. I think they have an interest in better security.
Posted Feb 12, 2009 14:50 UTC (Thu)
by cate (subscriber, #1359)
[Link] (1 responses)
Posted Feb 12, 2009 20:46 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 17, 2009 18:50 UTC (Tue)
by lyeoh (guest, #56701)
[Link] (1 responses)
If you expect people to figure out whether a file is safe before "launching/opening" it, then you are expecting people to solve something similar to the "halting problem" (which I heard is very hard).
Thus I propose that:
Do note there's also:
I have proposed this concept before to Ubuntu and Suse, see:
It'll be hard to implement, but I suspect it's easier than getting people to reliably solve the "halting problem", and in typical cases solve the halting problem without even being able to look at the actual source code.
Posted Feb 17, 2009 20:19 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link]
The halting problem is not hard to solve. It's IMPOSSIBLE to solve. See Wikipedia for info. As for your proposal, I don't know how wise it is to resort to the "bug the user" idea, when that's been shown to induce users to just click through things in annoyance.
Posted Feb 12, 2009 16:58 UTC (Thu)
by nedu (guest, #50951)
[Link] (1 responses)
Why don't desktop files start ... of course it's an fdo standard ... The FDO Desktop Entry spec provides that comments may begin with a hash. So beginning with a sh-bang line shouldn't be a problem for existing Gnome or KDE environments.
Desktop Entry Specification: Comments
Lines beginning with a # and blank lines are considered comments and will be ignored, however they should be preserved across reads and writes of the desktop entry file. Of course, just 'cause the FDO “standard” sez something, doesn't mean that implementations actually do that. But, at least, my version of Nautilus doesn't choke on hash-marked comments.
Posted Feb 12, 2009 20:55 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 11, 2009 22:54 UTC (Wed)
by jengelh (subscriber, #33263)
[Link] (8 responses)
And don't forget the PEBKAC. Telling users to rm -Rf still yields an occassionall hit.
Posted Feb 12, 2009 2:36 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
but you don't want to hang the users out to dry.
My biggest pet peeve, for example, is when people tell other people that they are stupid for double clicking on a attachment in a email that ran a program that installed a virus.
It's very irritating because double clicking is about the only way to interact with the system. And _no_shit_ attachments in email can be dangerous, but why does the system react to double click in the most dangerous manner possible?
Users are trained by the UI to double click on everything and see what happens. So it's like it's a trap... extremely bad UI design.
So probably the policy for the UI is not to do anything automatically unless it's safe.
The unfortunate problem is that programs react the same if it's safe data vs having untrusted data.
------------------
Of course you shouldn't go out of your way to protect stupid users. If they insist on doing something potentially stupid then you should let them. Just don't do it automatically for them.
Something like that.
Posted Feb 12, 2009 12:43 UTC (Thu)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Feb 12, 2009 17:08 UTC (Thu)
by drag (guest, #31333)
[Link]
For example a common attack vector is to use HTML email to exploit flaws in Microsoft's HTML rendering technology. Using javascript or other things like that to exploit weaknesses that were discovered and 'patched' in Internet Explorer.
Another one is using built in languages for applications to execute virus-like things. For example Word Macro viruses were very very popular.
-------------------------
So... say in Linux there is a flaw in Envice's PDF rendering method some were. So you could send a legal PDF over email that when executed by Evince it would exploit that flaw and run some shell code.
Since there is no security internal to a user account or desktop any program, even the most trivial and unimportant, with a exploitable flaw can be used to gain full access to anything and everything on that user's desktop..
This example is just targeting Nautilus or Konquerer to do a oversight in the .desktop standard... but any program that is commonly used to handle files downloaded from the internet has the same potential problems.
------------------------------
With Linux having a generic attack like with Word Macros or Win32 HTML rendering flaws probably won't work.
So worms and viruses won't spread. The environments are to diverse and are patched too quickly for a generic attack to work in that manner.
This is, in fact, what makes Linux resistant to viruses even though the Linux binary formats makes it very easy to write viruses.
HOWEVER this does not make Linux resistant against focused attacks. If a attacker knows what desktop your using and knows that there are flaws in some of the software your using on your desktop then they could create a focused attack that, if they are targeting a corporate desktop install (for example) with hundreds of users, then they can have a very high probability of success.
Posted Feb 12, 2009 9:03 UTC (Thu)
by renox (guest, #23785)
[Link] (4 responses)
I'd argue that a sensible designer should choose meaningful name for dangerous actions.
Posted Feb 12, 2009 15:43 UTC (Thu)
by jhardin (guest, #3297)
[Link] (3 responses)
You're assuming that they know what "recurse" means. :)
delete --subfolders --noconfirm
Posted Feb 12, 2009 16:13 UTC (Thu)
by jengelh (subscriber, #33263)
[Link] (2 responses)
Posted Feb 13, 2009 8:04 UTC (Fri)
by muwlgr (guest, #35359)
[Link] (1 responses)
Posted Feb 13, 2009 9:49 UTC (Fri)
by jengelh (subscriber, #33263)
[Link]
Posted Feb 12, 2009 14:18 UTC (Thu)
by pboddie (guest, #50784)
[Link]
It's like RISC OS's !Boot file mechanism where the desktop environment would scan application directories and run !Boot files to set up icons and file types (and potentially do other stuff): supposedly great for convenience, but a great way of spreading malware in a way not dissimilar to the "autorun" behaviour of media under Windows (where the malware may well be some media company's latest rootkit). A quick review of prior art would surely have paid dividends here, but I guess (or would hope) that the ROX Desktop people guard against such attacks, at least, given the RISC OS inspiration of that project. Everyone else should do less posturing and more homework.
Posted Feb 11, 2009 20:35 UTC (Wed)
by jmorris42 (guest, #2203)
[Link] (9 responses)
> What happened in more than two years?
Exactly nothing. Because the leading lights in both the GNOME and KDE camps do not see themselves as UNIX users, do not intend to 'inflict' UNIX design decisions on their users and just generally have the attitude that they are supplanting UNIX, not extending it. The relationship between OS X and Darwin is their guidestar. Or more bluntly, that they draw their inspiration from Windows and the Mac and despise *NIX. They consent to be hosted on *NIX/X because it is the only game in town and doing so lets them get on with the GUI stuff they like and forget about the operating system details.
Make all .desktop files executable and the problem doesn't exist. That this IS a problem waiting to happen has been obvious for years and the downside to the change is pretty close to zero. This is a failure in design philosophy. Push a devel in a corner and make em explain and I'd bet money it would involve a more weasel worded version of "Windows doesn't have an executable flag, thus it would confuse new users. Getting new users is the be all end all arguments priority."
Posted Feb 11, 2009 21:13 UTC (Wed)
by aleXXX (subscriber, #2742)
[Link] (6 responses)
Being a KDE developer myself, I can assure you that this is simply not
Alex
Posted Feb 11, 2009 21:47 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (5 responses)
aleXXX wrote: Being a KDE developer myself, I can assure you that this is simply not true.
I'm willing to give KDE some grudging benefit of the doubt, but some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX.
And although .desktop files are a "standard", they are a terrible idea. They are a clear security danger.
I have e-mailed the security contacts at both kde.org and gnome.org. I fully expect them to ignore the issue, at which point I will have to write an article retracting my original opinion (from 2001) that Linux is more resistant to e-mail trojans than Windows. What a sad state of affairs.
Posted Feb 12, 2009 7:58 UTC (Thu)
by ovitters (guest, #27950)
[Link] (3 responses)
Ignoring your statement about Miguel, could you give another example? I'm involved in GNOME and I think your statement is not true. Further, Miguel isn't involved with GNOME anymore (only relation is that he started it, etc). From what he said himself, he only attends e.g. GUADEC as an interested user (plus it is fun). We don't have a security contact (unless it changed over the last few months).
Posted Feb 12, 2009 14:20 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (2 responses)
bkor wrote: We don't have a security contact (unless it changed over the last few months).
Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail.
Ignoring your statement about Miguel, could you give another example?
I cannot give names, because I don't know any. But I'll give an example of anti-UNIX behaviour: I've asked for various GNOME tools such as evolution to support an external editor; shelling out to an external editor is time-honoured UNIX behaviour. This request has been met with reactions of various degrees of hostility, from "go away, we're too busy" to downright derision.
I don't mean to go on an anti-GNOME rant. But you did ask! (For the record, I don't use KDE either.)
Posted Feb 12, 2009 18:26 UTC (Thu)
by ovitters (guest, #27950)
[Link] (1 responses)
Or that is the wrong address. Just mailing some random thing is not a promise that it is the right method. Ah, so you're feature request wasn't implemented. Oh well, I wouldn't call it anti. I do want to know in which bugreport you interpreted someones remark as derision. Feature requests can be rejected, but people have to be respectful. Btw, Evolution has a plugin to use an external editor.
Posted Feb 13, 2009 2:21 UTC (Fri)
by k8to (guest, #15413)
[Link]
No, one of two things he or she said is true regardless of your postulation. Your comment may be pretty relevant to the right way of going about things, of course.
However, gnome does all kinds of things totally wrong in a manner that shows a failure to understand UNIX.
Gnome libraries don't even understand what standard error is for. They think it's standard debug or something. A typical gnome program has so much library spew that you couldn't ever possibly notice a real problem that the application you're using is trying to tell you about.
Posted Feb 12, 2009 11:32 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Let me point out that the desktop file standard is heavily based on kdelnk format from KDE. A anti-GNOME rant is going to fix any potential security issues with a cross-desktop standard format at this point.
Posted Feb 12, 2009 8:57 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Feb 13, 2009 16:35 UTC (Fri)
by geohump (guest, #27792)
[Link]
Dear Mike, I'm sorry but you seem to have misunderstood both why GNU is called GNU and why Linux is Linux. RMS was not "distancing" GNU from UNIX. RMS was making a free CLONE of UNIX. RMS intended GNU to be an exact functional replacement for UNIX. You might want google up the original postings to usenet from RMS about the project.
RMS named GNU "GNU" as part of his way of making clear that GNU was to be completely free of any the original UNIX intellectual property despite being a clone of UNIX. Do you suppose that its just an accident that every tool the GNU folks built had exactly the same name and function as their UNIX counterparts? (And tweaks as well. I never met a programmer yet who could resist the chance to "flavor the pot" to their own personal taste when they could get away with it. :-) )
Both the GNU and Linux efforts were created in order to give the people who loved the power and elegance of UNIX, a free version of UNIX, complete with source code to work on themselves, without having to purchase an AT&T/Bell Labs source code license.
Your idea that GNU and LINUX are not UNIX show that you missed the conversation that happened at the time of their creation. The GNU tools and Linux were made to be as much like the original UNIX as they could be in every way that matters to programmers, while maintaining total separation from any of the source code from ATT/Bell so that they would be free from licensing costs and restrictions. If all you care about is the name "UNIX" being licensed, then you were never a UNIX or Linux person anyway.
For those who say Linux is not a "UNIX" because its not perfectly identical to UNIX, I say: "Hey thanks for the belly laugh!" Linux is just as identical to UNIX as ULTRIX, HP-UX, Domain-IX, SUNOS, BSD, AIX, SCO, and all the other "legal UNIX licensees" are to each other and to the original ATT/BELL UNIX (assuming you can resolve the differences between the teeming masses of UNIX versions Bell put out itself! How many were there? 20? 30? )
Your claims that names should be longer 3 or 4 chars and that "Modern systems" have both PATH and "tab complete" are amazingly lacking. UNIX and its clones/variants have had those for more than 25 years. In fact PATH was there in the 1970's. Probably longer than you've been alive. (Personally I approve of keeping comamnd names somewhat short as long as there is a mnemonic relationship in the name. Why make people type more than they have to? (Excuse me, I meant "cat" not "type" :-) Well, OK, cat isn't the best example of a mnemonic. :-) ) ) (Note these are parenthetical side notes, not Lisp code. ( Hey, these ARE the jokes folks! ) )
As for liking Python. Thats great. New languages come out of the UNIX/Linux environments all the time. UNIX/Linux even has tools for generating new languages. You are, of course, totally familiar with Lex and yacc. :-) What I especially like about python is how well it integrates with the "standard" UNIX/Linux environment. :-) That liking python might imply anything is wrong with the UNIX/Linux tools is an interesting notion.
The GNOME desktop vulnerability is a clear example of why the UNIX design legacy is a good one, well thought through and still applicable today. That vulnerability exists because the GNOME folks are trying to make LINUX just like Windows and sadly, within the confines of their project, they are suceeding. They are even introducing the typical Windows security issues!. Happily no one has to use GNOME and therefore Linux users can remain free of this Ballmer-esque disease of corruption. (Hey guys - try throwing a chair at your design, maybe that will improve it. ) The Gnome project is an excellent example of people ignoring the UNIX design philosophy and paying the price.
"Those who do not understand UNIX will re-invent it. Poorly." Has never been more true than today.
The quality of the UNIX design philosophy is becoming more and more clear as time goes forward. Even MS is busy today adding more and more UNIX-Like features to their OS. :)
Does this mean that Linux has to stay the same? Absolutely not. New features can and are being added all the time. Lets just make sure those new features are really new, not copies of MS mistakes and that those features actually work the way they need to, including security.
[N.B.]
By creating a clean room style clones of UNIX, GNU and Linux gave a version of UNIX to the worlds programmers that they could use in a totally unrestricted fashion. The key point being that the GNU tools and Linux system WERE UNIX CLONES. Thats WHY they are and were so popular. Legally, NOT licensed from ATT/Bell, Functionally and design-wise - as darned near identical as they could be made to be by the best efforts of their creators. (subject to the perfidies of ego, of course. :-) )
The naming of GNU was done to emphasize the free licensed nature of GNU. Otherwise it was a functional clone (plus more) of UNIX tools.
Final postscript: To those who will try to play "geek gotcha" with this comment by finding obscure techno arcana or tortured interpetations of the above statements repurposed to support things other than what was said in the context above, you fail. The above posting is about the philosophical spirit of UNIX which GNU and LINUX completely engender and not about the legal-word-smithing typical of the "We-add-no-value-but-we-have-lawyers" approach typical of some people and companies. By trying the latter approach you actually support the statements made above. The spirit, not the letter rules here.
Posted Feb 11, 2009 18:04 UTC (Wed)
by stevenj (guest, #421)
[Link] (5 responses)
From my perspective, any user interface that employs the same action to open a file as to launch an executable/script has a fundamental vulnerability to social-engineering attacks.
Posted Feb 11, 2009 18:35 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
Posted Feb 11, 2009 19:41 UTC (Wed)
by NAR (subscriber, #1313)
[Link]
Posted Feb 12, 2009 0:37 UTC (Thu)
by stevenj (guest, #421)
[Link] (2 responses)
Clearly, some UIs are more vulnerable than others. (To pick an extreme example, a mail UI that allows merely reading an email to execute untrusted code is problematic.)
Posted Feb 12, 2009 16:01 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
My point was that user's education helps 100 times more then any UI
decisions.
Posted Feb 12, 2009 19:13 UTC (Thu)
by stevenj (guest, #421)
[Link]
Posted Feb 11, 2009 20:39 UTC (Wed)
by mikov (guest, #33179)
[Link] (6 responses)
Does anybody know whether anything is being done to address this specific vulnerability? We may laugh at Microsoft, but Vista's UAC, incredibly annoying as it is, is at least a serious attempt to solve this problem.
Posted Feb 11, 2009 22:09 UTC (Wed)
by jmorris42 (guest, #2203)
[Link] (5 responses)
I doubt a solution will ever get deployed until it gets exploited in the wild. The solution however is fairly obvious. Pass an environment variable declaring the path of the .desktop file and have important things like gksu check that it didn't get invoked from an unexpected/insecure location.
Posted Feb 12, 2009 3:33 UTC (Thu)
by k8to (guest, #15413)
[Link] (4 responses)
What is the attack vector?
If menus are able to be modified, this sounds like writes can be made to the filesystem, in which case the environment variable can be erased.
my.desktop:
my_script.sh:
Maybe I don't understand what your proposal is guarding against.
Posted Feb 12, 2009 8:27 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (3 responses)
I was thinking about the problem in the article where you can replace the menu entry for an elevated privledge tool like packagekit with an entry in the users home directory and as long as the name and group are identical it will silently replace the systemwide entry in the menus.
But yea, an environment variable isn't going to be secure. Doh. Should have pondered that one a few more minutes. So what would be? If gksu can learn (reliably) how it got invoked the exploit goes away.
Posted Feb 12, 2009 10:18 UTC (Thu)
by efexis (guest, #26355)
[Link] (2 responses)
Posted Feb 12, 2009 18:49 UTC (Thu)
by mikov (guest, #33179)
[Link] (1 responses)
Posted Feb 12, 2009 19:26 UTC (Thu)
by efexis (guest, #26355)
[Link]
...I can't disable it...
I really didn't think that one through.
What I should've done was make the su app give *me* a system identifying password, which I then respond with the second half. Imitation *su apps wouldn't be able to read the challenge string, so I would never be fooled by something that merely asked me for a password.
Posted Feb 11, 2009 21:19 UTC (Wed)
by endecotp (guest, #36428)
[Link] (2 responses)
(I suppose that still leaves MIME types like text/perl to worry about.)
Posted Feb 12, 2009 9:52 UTC (Thu)
by roblucid (guest, #48964)
[Link]
Unfortunately it seems to be very tempting, to add "kool" dynamic content, by using over-general languages because it ticks the maximum number of feature lists.
Posted Feb 12, 2009 19:58 UTC (Thu)
by GhePeU (subscriber, #56133)
[Link]
Posted Feb 11, 2009 21:21 UTC (Wed)
by ledow (guest, #11753)
[Link] (6 responses)
"How to write a Linux virus in 5 easy steps" is a false title. It should be called:
"How to write a text file which, when downloaded deliberately and placed into a certain location, and then double-clicked, could potentially execute code within the context of the user account that ran it."
That's called a bash script, or even a rogue Makefile, or a malicious line of C code. In fact, all of my suggestions are simpler and more likely and the last two don't need eXecution rights either. I hide a rogue line of script inside one of those, get you to download my software and try to install it and bam... instant compromise (and an awful lot of people compile as root!).
The problem of viruses is NOT that the user that runs them might lose their files or be bombarded by ads. They were a moron to run the program and it could do anything they have permission to, otherwise the system wouldn't work. The problem is that the virus can self-propogate, cause damage, be difficult to remove and compromise the MACHINE. This is almost impossible as anything other than a superuser on Linux. This is the difference between Linux and Windows.
Users run stupid things all the time. "rm -f" comes to mind and causes a lot of damage. Anybody with access to a compiler from their user account can cause merry hell without even meaning to. The point is that after a reboot, or a removal of their user area and a kill of their processes, there is NOTHING left to affect any other user of that machine. That's just not true of Windows.
This isn't a Linux, KDE, Gnome problem. It's a user-is-an-idiot-and-did-something-that-could-trash-HIS-files problem. I get *those* every day.
Posted Feb 12, 2009 0:12 UTC (Thu)
by tbrownaw (guest, #45457)
[Link] (2 responses)
I thought the ones that could self-propagate were called "worms".
Posted Feb 12, 2009 3:30 UTC (Thu)
by nlucas (subscriber, #33793)
[Link] (1 responses)
Basic example, a bash virus runs, look for other bash scripts and inserts itself at the start of the existing script (eventually first checking if it was already infected). It may now check if it's time to do it's think ("rm -rf ~/*") or just exit and wait the user to make it run again by executing an infected script.
A worm runs by itself. Doesn't need a "host" program to run, but off course it needs some way of start running, and that can possibly be by adding itself to be called at the end of .bashrc/.profile/.whatever.
In the old days, the difference was that virus were writen in assembly, because they couldn't use something like libc, while worms, being a full programs, could be written in anything (and so, could be more powerful, like using system network libraries for infection).
Posted Feb 12, 2009 10:43 UTC (Thu)
by efexis (guest, #26355)
[Link]
Posted Feb 12, 2009 11:31 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (2 responses)
Saving a bash script or Makefile from a web browser or email client, and then double-clicking the resulting file, will result in the file being opened in a text editor.
Doing the same to an ELF binary will (at least on my GNOME 2.24 system) result in a dialog box saying: "Cannot open $FILE. There is no application installed for this file type".
This is because web browsers, email clients, etc, will save the evil file out, but will not mark the file as executable. Without being executable, these files are harmless text and binary files and are treated as such.
The loophole here is that if the user extracts files from a tar or zip archive, the archiver will mark evil files executable if the archive says so. In fact, for some reason I cannot fathom, unzip will mark *all* extracted files as executable! In my opinion, all files extracted by archivers should not have their permissions restored unless the user specifically requests it.
Note that I do not address bugs in file viewing programs themselves; e.g., a vulnerability in a PDF reader or imgae displayer that causes it to execute arbitrary code embedded in an evil file.
Anyway, to return to my point; the special processing that allows a .desktop file to appear with any arbitrary file name and icon, and that allows them to execute any arbitrary code should be disabled for .desktop files that are not executable. That simple change eliminates this problem.
The first public discussion of this problem that I could find occured in 2006; Unfortunately, the freedesktop.org people simply don't seem to care that they have created such serious security problems by ignoring the security features inherited from Unix so many years ago; essentially reducing the security level of the Linux desktop to that of Windows 3.
It is a shame that implementors (GNOME, KDE, etc.) have not taken matters into their own hands and disabled special processing for non-executable .desktop files themselves; and in turn, that distributors (Debian, etc.) have not acted where implementors have failed to do so.
Posted Feb 13, 2009 2:28 UTC (Fri)
by k8to (guest, #15413)
[Link]
The problem is that there are some retarded zip programs out there that mark everything executable.
Posted Feb 21, 2009 23:16 UTC (Sat)
by miketrim (guest, #54570)
[Link]
Posted Feb 12, 2009 1:04 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
All the admin desktop files on my machines seem to simply run consolehelper. If consolehelper decides that I'm authorised to run the named program, then it uses its privileges to run the actual program itself. So you can't trick it into running some arbitrary shell script with root privileges.
Personally I'd be happy to see +x required for desktop files to do more than sit there idly as text files, but I won't hold my breath.
Overall though I don't support this "Linux can't get a virus" (or Mac or Vista or fill in whatever OS you favour) silliness and I don't think we should be pretending that people who are vulnerable to social engineering can be effectively protected by OS design. Most people who'd get caught by this "fake nude pictures email" approach aren't going to be saved by a tweak like requiring +x on desktop files.
Posted Feb 12, 2009 11:01 UTC (Thu)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link]
Posted Feb 13, 2009 8:12 UTC (Fri)
by muwlgr (guest, #35359)
[Link] (1 responses)
Posted Feb 13, 2009 23:24 UTC (Fri)
by mlankhorst (subscriber, #52260)
[Link]
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
interpreted in order to be run. Why don't desktop files start
(then a normal .desktop file, as now)
any user can run .desktop files easily... of course it's an fdo standard,
but surely this change (one line and an interpreter binary) is worth it?
This is so obvious that I'm wondering why the hell it wasn't in the
standard all along.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
And how would it interact with the standard permissions?
How to write a Linux virus in 5 easy steps
When the launcher is invoked as an executable through the hash-bang mechanism with the executable bits off, it will refuse to run anyway, and when run by the interpreter you have the current situation.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
specialized program that knew how to run .desktop files; and it checks the
executable bit on .desktop files that are passed to it as parameters
*itself* before launching programs named in them: it doesn't leave this up
to the kernel or anything like that.
What I meant is that you cannot be sure that there actually is trusted content in that launcher file, so the DE would still have to verify that it would actually run the launcher interpreter, to start with. The executable bit would tell the DE to trust the content, because presumably the user has seen the content, and that is not such a great idea.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
of sticking with current DEs and .desktop files (without a hashbang) while
simultaneously securing against this attack.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
just that the first stage of that is to check that the user can execute
them. :)
execute things from a .desktop. Centralize such knowledge in a single
carefully-audited tool.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
environment development groups, really, because it's useless unless they
adopt it.
line as well, I suppose.)
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
which is readable is also executable! Classical examples: execute the
program as argument of the dynamic linker, executing scripts using the
interpreter. Eventually a copy of the program and then changing permission
bits. In short time the exploiters could use such work-arounds. So
execution bit should not be used for security reasons
How to write a Linux virus in 5 easy steps
for .desktop files, which does all the parse-and-launch stuff. *It* checks
the state of the executable bit on the .desktop files that it is invoked
with, and *nothing else runs programs named in .desktop files at all*.
A possible solution might look like this
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.
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.
https://bugs.launchpad.net/ubuntu/+bug/156693
A possible solution might look like this
sh-bang line for desktop entry files
#!/usr/bin/desktop-interpreter
sh-bang line for desktop entry files
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
It's very irritating because double clicking is about the only way to interact with the system. And _no_shit_ attachments in email can be dangerous, but why does the system react to double click in the most dangerous manner possible?
Absolutely right. Double-clicking on an icon should and must be a safe operation. It should *open* the file, not execute it. The only things that can be safely executed are programs specifically installed as executable, either through the system package manager or by the user (or desktop environment) marking them as such.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
[ Yes I know that 'cp /dev/zero /dev/hda' would work too but for this to work you need to be root ]
How to write a Linux virus in 5 easy steps
If you're going to be verbose in an attempt to shield unsophisticated users, don't lose sight of your target audience.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
(SCNR-reiser-joke-after-everybody-else-had-theirs-already.)
Special desktop files and untrusted media
Well they are not executed, per say, but they are interpreted by your nautilus browser.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
> themselves as UNIX users,
true.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX
I have e-mailed the security contacts at both kde.org and gnome.org
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail.
But I'll give an example of anti-UNIX behaviour
How to write a Linux virus in 5 easy steps
Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail.
Or that is the wrong address. Just mailing some random thing is not a promise that it is the right method.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
>stands for? That is not just a joke name. Linux is also
>not Unix for that matter.
To those who will inevitably protest that GNU and Linux aren't "UNIX", You are technically correct but only in terms if licensing. And that is true for good reason. It was made deliberately true by the GNU and Linux founders to make sure that GNU and Linux would be FREE of the ATT/Bell licensing encumberances and costs. Unlike all the flavors of UNIX, and there were quite a few, which were all hampered and restricted by the ATT/Bell labs ownership and licensing.
Albeit in the comments, not in the article text, of yet another article about email viruses: "Not to mention that certain things like desktop shortcuts on GNOME are just files and don't need an execute bit at all to be usable in dangerous ways." And there are other time-tested (on Windows) ways of getting users to set executable bits, e.g. by getting them to uncompress a .tar.gz file (a lot of Windows email viruses hid themselves in .zip attachments).
actually, was pointed out at least as early as 2004 on LWN.net
Way too long phrase...
From my perspective, any user interface that employs the same
action to open a file as to launch an executable/script has a fundamental
vulnerability to social-engineering attacks.
Should be read:
any user interface has a fundamental vulnerability to social-engineering
attacks. It does not mean .desktop files should be runnable without X
attribute, of course - it just means it's not a panacea...
Yes, the file opening application can also have a bug that is triggered by the malicious attachment...
Way too long phrase...
Is your point that UI design plays no role in security, or that nothing can be done to improve the situation? If so, I have to respectfully disagree. If not, I'm not sure what your point is.
Way too long phrase...
My point?
Even if this were true (do you have data to back it up?), it wouldn't imply that resistance to deception should not play a significant role in UI design. Clearly, no approach is a panacea, which means that one wants to explore all practical avenues; certainly user education hasn't prevented widespread malware on certain platforms (which has side effects affecting all of us).
My point?
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
> this specific vulnerability?
How to write a Linux virus in 5 easy steps
exec=sh my_script.sh
unset UNSAFE_SOURCE
gksu rm -rf /
How to write a Linux virus in 5 easy steps
> to the filesystem, in which case the environment variable can be erased.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
Why arbitrary executables?
Why arbitrary executables?
Can anyone suggest a sane use-case where a .desktop file needs to specify an arbitrary executable? I would have thought that in 99% of the uses of these things they should indicate their MIME type (or equivalent) and the desktop should use that to determine the executable to run.
Why arbitrary executables?
You got it backwards: the .desktop files are what the system use to decide what executable must be used to open a file with a specific MIME type.
$ cat /usr/share/applications/gedit.desktop
[Desktop Entry]
Name=Text Editor
Comment=Edit text files
Exec=gedit %U
Terminal=false
Type=Application
StartupNotify=true
MimeType=text/plain;
Icon=accessories-text-editor
Categories=GNOME;GTK;Utility;TextEditor;
When nautilus finds a file with the mimetype 'text/plain' it looks through all the .desktop files in the system- and user-specific directories until it finds one who lists the correct mimetype and launch the indicated executable with the specified parameter.
To gnome-menus the same file means "add to the Accessories menu an entry named 'Text Editor' with the tooltip 'Edit text files' and the icon 'accessories-text-editor', then if the user click on this entry launch the command 'gedit'".
A .desktop file needs to specify an arbitrary executable.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
The problem is that the virus can self-propogate, cause damage, be difficult to remove and compromise the MACHINE.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
> of C code. In fact, all of my suggestions are simpler and more likely and
> the last two don't need eXecution rights either. I hide a rogue line of
> script inside one of those, get you to download my software and try to
> install it and bam... instant compromise (and an awful lot of people
> compile as root!).
How to write a Linux virus in 5 easy steps
Info-zip added an extra informational header that allowed permissions to be described in zip files. If your zip files have this informational field, and it says the files should be executable, they are created as such.
In Ubuntu/GNOME, any automounted FAT/NTFS drives are mounted with umask=0077 which results in all files being executable. This was something I found rather annoying when I migrated from Windows, as all my files that I copied over were initially marked +x, resulting in Nautilus always asking if I wanted to view or execute them.How to write a Linux virus in 5 easy steps
However, this could just as easily be a security issue as it means that Nautilus will happily execute files stored on a USB drive for example. (Double-clicking on a +x binary will execute it without any confirmation, and the same can apply to a +x text file if Nautilus is configured to do so -- or if the user doesn't understand the difference between 'run' and 'view'.)
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/14335
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps
After all Unix is multi-user and each user has his own access right, the user/group "internet/internet" cannot change the current user menu - but still show that postcard with sound they are talking about in the E-mail.
How to write a Linux virus in 5 easy steps
How to write a Linux virus in 5 easy steps