| |||||||||||||
|
| |||||||||||||
How to write a Linux virus in 5 easy stepsHow to write a Linux virus in 5 easy stepsPosted Feb 11, 2009 18:25 UTC (Wed) by drag (subscriber, #31333)In reply to: How to write a Linux virus in 5 easy steps by rvfh Parent article: How to write a Linux virus in 5 easy steps
Well they are not executed, per say, but they are interpreted by your nautilus browser.
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.
(Log in to post comments)
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 18:43 UTC (Wed) by drag (subscriber, #31333) [Link]
Probably the solution here is to use SeLinux/Smack or perhaps a simpler LSM to provide two security contexts for the Linux desktop. Or maybe just something built into nautilus or whatever.
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.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 19:42 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
One could also the permissions of user applications to do anything dangerous (including accessing the net or file I/O) in a PolicyKit-like way. Then one application could be kept from accessing another applications files (or generally, files with a mime type that it is not supposed to handle), and it could be kept from overwriting any files except the one it had opened. If the applications were hardened à la Chrome so that one process handled one document, they could even be prevented from reading documents other than the one they were currently editing. Basic tools like ls or whatever could still work as expected, but the limited applications would not be allowed to run them.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 20:35 UTC (Wed) by nix (subscriber, #2304) [Link]
Well, that's just stupid. We *have* a way to implement things that must be
interpreted in order to be run. Why don't desktop files start
#!/usr/bin/desktop-interpreter
That would fix all these problems. Executable permission is now required,
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 21:25 UTC (Wed) by drag (subscriber, #31333) [Link]
Well the .desktop thing can probably be fixed in that manner, but the fundamental problem is that there is no divisions or security within a user's environment.
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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 10:51 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Interesting idea, but I have to wonder what such a thing would even look like. How would such a system work, and how would the user interact with it?
And how would it interact with the standard permissions?
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?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 12:55 UTC (Thu) by nix (subscriber, #2304) [Link]
If it's not trusted, turn the executable bit off, and have the interpreter refuse to run something if the executable bit is off (so that "/usr/bin/desktop-launcher /tmp/bad-not-executable.desktop" would fail).
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:08 UTC (Thu) by hppnq (subscriber, #14462) [Link] 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.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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 20:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, yes, the .desktop-launching interpreter would of course be a
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.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:57 UTC (Fri) by hppnq (subscriber, #14462) [Link] 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.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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:24 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Right, but that requires modifying the interpreter program. What can we do that would accomodate current software?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 20:49 UTC (Thu) by nix (subscriber, #2304) [Link]
DEs need changing for this (as do the .desktop files). I can't see a way
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 Posted Feb 12, 2009 21:11 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
What do you mean by "DEs"?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 22:11 UTC (Thu) by nix (subscriber, #2304) [Link]
DE = desktop environment.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 22:16 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Alright, that makes sense.
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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 23:29 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, its job is to exec() the programs specified in .desktop files: it's
just that the first stage of that is to check that the user can execute them. :)
I don't see any reason why anything else in the DE needs to know how to
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 1:02 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
That does make sense. It could even be a desktop environment-agnostic tool, such that it would work with GNOME, KDE, XFCE, or what have you, without any changes. Make it depend on minimal libraries (I think you'd only need libc, actually), and make it universally available. For maximal adoption, I'd think you'd want it to be permissively licensed, ala the X.org license.
Y'know, this could work! Gonna write it yourself?
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:04 UTC (Fri) by nix (subscriber, #2304) [Link]
I'd like to, but to be useful it has to come out of one of the desktop
environment development groups, really, because it's useless unless they adopt it.
(... actually, not all that useless: it could be useful from the command
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 16:29 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Well, all it really has to do is examine a .desktop file's permissions and ownership, and return success if they're good, or failure if they're bad. That could be used from any environment.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 17:03 UTC (Fri) by nix (subscriber, #2304) [Link]
I was expecting it to handle the Exec line itself: i.e., with this in place, running an executable-marked .desktop file from bash would exec() the command stated in its Exec line, by way of the interpreter.
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!)
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 17:06 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Oh, right, I knew that. Just forgot.
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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:50 UTC (Thu) by cate (subscriber, #1359) [Link]
The "executable bit" is only an hits (for program in path). Every program,
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 Posted Feb 12, 2009 20:46 UTC (Thu) by nix (subscriber, #2304) [Link]
You don't get it. The interpreter is a specialized interpreter
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 Posted Feb 17, 2009 18:50 UTC (Tue) by lyeoh (guest, #56701) [Link]
A lot of people claim it's a PEBKAC problem, but I 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 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.
A possible solution might look like this 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.
sh-bang line for desktop entry files Posted Feb 12, 2009 16:58 UTC (Thu) by nedu (guest, #50951) [Link]
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.
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.
sh-bang line for desktop entry files Posted Feb 12, 2009 20:55 UTC (Thu) by nix (subscriber, #2304) [Link]
True. However, IMNSHO starting with a hashbang should be *mandatory* :)
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 22:54 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>The _Linux_system_ is relative secure, but as far as user accounts on the desktop there isn't much protections.
And don't forget the PEBKAC. Telling users to rm -Rf still yields an occassionall hit.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 2:36 UTC (Thu) by drag (subscriber, #31333) [Link]
Well ya.
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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 12:43 UTC (Thu) by epa (subscriber, #39769) [Link] 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 Posted Feb 12, 2009 17:08 UTC (Thu) by drag (subscriber, #31333) [Link]
Well don't forget that opening malicious documents in applications can have the same effect as executing a binary.
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.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 9:03 UTC (Thu) by renox (guest, #23785) [Link]
Not only a PEBKAC.. 'rm -Rf' works because the command name is obscure, telling users to type 'delete -recurse -noconfirm' would be far less successful..
I'd argue that a sensible designer should choose meaningful name for dangerous actions.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 15:43 UTC (Thu) by jhardin (guest, #3297) [Link]
> telling users to type 'delete -recurse -noconfirm' would be far less successful.
You're assuming that they know what "recurse" means. :)
delete --subfolders --noconfirm
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 16:13 UTC (Thu) by jengelh (subscriber, #33263) [Link]
Directories, directories. Shitty Windows "folder" terminology, even Microsoft once knew better during DOS times.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 8:04 UTC (Fri) by muwlgr (guest, #35359) [Link]
What about that thing called "Active" Directory ? :>
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:49 UTC (Fri) by jengelh (subscriber, #33263) [Link]
That's probably a circumscription for a reiser-backed data storage, because normal directories are pretty much static and inactive by themselves.
(SCNR-reiser-joke-after-everybody-else-had-theirs-already.)
Special desktop files and untrusted media Posted Feb 12, 2009 14:18 UTC (Thu) by pboddie (guest, #50784) [Link] Well they are not executed, per say, but they are interpreted by your nautilus browser. 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.
|
|
||||||||||||