| |||||||||||||
|
| |||||||||||||
How to write a Linux virus in 5 easy stepsHow to write a Linux virus in 5 easy stepsPosted Feb 12, 2009 10:51 UTC (Thu) by flewellyn (subscriber, #5047)In reply to: How to write a Linux virus in 5 easy steps by drag Parent article: How to write a Linux virus in 5 easy steps
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?
(Log in to post comments)
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.
|
|
||||||||||||