How to write a Linux virus in 5 easy steps [LWN.net]

Here's a weblog posting by "foobar" describing an attack vector for desktop Linux systems. "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).

to post comments

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 17:29 UTC (Wed) by rvfh (guest, #31018) [Link] (47 responses)

Is it that these files still (since 2006) need not be executable to be 'run'? I mean, isn't that basic UNIX stuff?

I am confused. What happened in more than two years?

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 18:25 UTC (Wed) by drag (guest, #31333) [Link] (36 responses)

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.

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 18:43 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

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 mjthayer (guest, #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] (23 responses)

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
(then a normal .desktop file, as now)

That would fix all these problems. Executable permission is now required,
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

Posted Feb 11, 2009 21:25 UTC (Wed) by drag (guest, #31333) [Link] (20 responses)

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] (19 responses)

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] (16 responses)

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 (guest, #14462) [Link] (2 responses)

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] (1 responses)

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 (guest, #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] (10 responses)

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] (9 responses)

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] (8 responses)

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] (7 responses)

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] (6 responses)

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] (5 responses)

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
execute things from a .desktop. Centralize such knowledge in a single
carefully-audited tool.

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 1:02 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (4 responses)

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] (3 responses)

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
line as well, I suppose.)

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 16:29 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (2 responses)

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] (1 responses)

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] (1 responses)

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] (1 responses)

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:
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

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] (1 responses)

Why don't desktop files start
#!/usr/bin/desktop-interpreter

... 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.

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] (8 responses)

>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 (guest, #31333) [Link] (2 responses)

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] (1 responses)

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 (guest, #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] (4 responses)

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.
[ 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

Posted Feb 12, 2009 15:43 UTC (Thu) by jhardin (guest, #3297) [Link] (3 responses)

> telling users to type 'delete -recurse -noconfirm' would be far less successful.

You're assuming that they know what "recurse" means. :)
If you're going to be verbose in an attempt to shield unsophisticated users, don't lose sight of your target audience.

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] (2 responses)

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] (1 responses)

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.

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 20:35 UTC (Wed) by jmorris42 (guest, #2203) [Link] (9 responses)

Ok, I probably shouldn't but I gotta go on a rant here.

> 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."

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 21:13 UTC (Wed) by aleXXX (subscriber, #2742) [Link] (6 responses)

> Because the leading lights in both the GNOME and KDE camps do not see
> themselves as UNIX users,

Being a KDE developer myself, I can assure you that this is simply not
true.

Alex

How to write a Linux virus in 5 easy steps

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 7:58 UTC (Thu) by ovitters (guest, #27950) [Link] (3 responses)

some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX

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).

I have e-mailed the security contacts at both kde.org and gnome.org

We don't have a security contact (unless it changed over the last few months).

How to write a Linux virus in 5 easy steps

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.)

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 18:26 UTC (Thu) by ovitters (guest, #27950) [Link] (1 responses)

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.

But I'll give an example of anti-UNIX behaviour

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.

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 2:21 UTC (Fri) by k8to (guest, #15413) [Link]

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.

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 11:32 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"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."

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 8:57 UTC (Thu) by mjthayer (guest, #39183) [Link] (1 responses)

Other people also like to distance themselves from Unix. Remember what GNU stands for? That is not just a joke name. Linux is also not Unix for that matter. Obviously Unix design decisions which are still appropriate today are worth keeping up, but is every legacy decision sacred? For instance, for many purposes I would rather user python than the old Unix standard tool collection. And surely names longer than three (or four) characters would be acceptable for standard directories now, in an age when modern systems have both PATH variables and tab completion at the command line :)

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 16:35 UTC (Fri) by geohump (guest, #27792) [Link]

>Other people also like to distance themselves from Unix. Remember what GNU
>stands for? That is not just a joke name. Linux is also
>not Unix for that matter.

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.]
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.

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.

actually, was pointed out at least as early as 2004 on LWN.net

Posted Feb 11, 2009 18:04 UTC (Wed) by stevenj (guest, #421) [Link] (5 responses)

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).

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.

Way too long phrase...

Posted Feb 11, 2009 18:35 UTC (Wed) by khim (subscriber, #9252) [Link] (4 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.

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...

Way too long phrase...

Posted Feb 11, 2009 19:41 UTC (Wed) by NAR (subscriber, #1313) [Link]

Yes, the file opening application can also have a bug that is triggered by the malicious attachment...

Way too long phrase...

Posted Feb 12, 2009 0:37 UTC (Thu) by stevenj (guest, #421) [Link] (2 responses)

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.

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.)

My point?

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.

My point?

Posted Feb 12, 2009 19:13 UTC (Thu) by stevenj (guest, #421) [Link]

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).

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 20:39 UTC (Wed) by mikov (guest, #33179) [Link] (6 responses)

Using gksu/kdesu to gain root privileges for the virus is really scary! All the virus needs to do is modify the user's own menu items, which it can do easily. That attack will probably work 100% of the times! Scary!!

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.

How to write a Linux virus in 5 easy steps

Posted Feb 11, 2009 22:09 UTC (Wed) by jmorris42 (guest, #2203) [Link] (5 responses)

> Does anybody know whether anything is being done to address
> this specific vulnerability?

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 3:33 UTC (Thu) by k8to (guest, #15413) [Link] (4 responses)

I'm unclear how this fixes anything.

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:
exec=sh my_script.sh

my_script.sh:
unset UNSAFE_SOURCE
gksu rm -rf /

Maybe I don't understand what your proposal is guarding against.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 8:27 UTC (Thu) by jmorris42 (guest, #2203) [Link] (3 responses)

> 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.

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 10:18 UTC (Thu) by efexis (guest, #26355) [Link] (2 responses)

No, you were on the right track; *su apps shouldn't be paying attention (as least where security decisions are concerned) to their launch environment, but should load their own (esp PATH, LD_PRELOAD etc) from a secured location outside of the users HOME (/etc etc) before launching anything. Still, if you can run stuff in system locations (/usr/{,s}bin etc) and pass command line parameters, you could still run eg, bash, and pass it your malicious script to run on the command line (now as root). You could have it so that .desktop files that launch *su have to have the suid root bits set for *su to obey their command... and I guess the *su program actually reporting the command that's going to be run right there with where it's asking the user to confirm the action would help out (if this is not the case already? I only ever use the system account (I am my own protection, I need not the computer to do that for me, but I guess that's not the norm) so I can't really comment on what is/isn't done so far)

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 18:49 UTC (Thu) by mikov (guest, #33179) [Link] (1 responses)

I think what you guys are forgetting is that the virus doesn't even need to run gksu/kdesu. It can display a window of its own that looks like the one from gksu and ask you for your password. Simple and effective! :-)

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 19:26 UTC (Thu) by efexis (guest, #26355) [Link]

Which is why I have a process running, inspired by phish filters and early viruses, that detects whenever I enter the key sequence that is my root password, and kills the process that's recieving those keys before I have chance to hit enter...

...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.

Why arbitrary executables?

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.)

Why arbitrary executables?

Posted Feb 12, 2009 9:52 UTC (Thu) by roblucid (guest, #48964) [Link]

That's the essential point. The desktop files saved should be data, that make requests of program interpreter's installed out of band. Then you need to have those data interpreters not have embedded script facilities within them, or ways to execute binary code in the data file.

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.

Why arbitrary executables?

Posted Feb 12, 2009 19:58 UTC (Thu) by GhePeU (subscriber, #56133) [Link]

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.

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

Posted Feb 11, 2009 21:21 UTC (Wed) by ledow (guest, #11753) [Link] (6 responses)

Well, after reading the article, I'm not "shocked" or "surprised". I just nodded and went... "Yes, and?"

"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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 0:12 UTC (Thu) by tbrownaw (guest, #45457) [Link] (2 responses)

The problem is that the virus can self-propogate, cause damage, be difficult to remove and compromise the MACHINE.

I thought the ones that could self-propagate were called "worms".

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 3:30 UTC (Thu) by nlucas (subscriber, #33793) [Link] (1 responses)

Both can self-propagate. The difference between a virus and a worm is that the first needs to "attach" itself to some other program to be run, while the worm IS the program.

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).

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 10:43 UTC (Thu) by efexis (guest, #26355) [Link]

Just like in biology! A virus masks as healthy DNA code so that host cells will copy it, whereas worms are host cells in their own right... of course this means one can actually use viruses to fight worms (bacteriophages), which is something that's used both in treating bacterial infections, and shutting down botnets (by using the botnet to spread the code that later kills itself). Aside from the damage all of this causes in the world of data and flesh, it's all rather cool!

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 11:31 UTC (Thu) by cortana (subscriber, #24596) [Link] (2 responses)

> 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!).

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.

https://robots.org.uk/DesktopEntryVulnerability

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 2:28 UTC (Fri) by k8to (guest, #15413) [Link]

By default, unzip does not mark files as executable.
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.

The problem is that there are some retarded zip programs out there that mark everything executable.

How to write a Linux virus in 5 easy steps

Posted Feb 21, 2009 23:16 UTC (Sat) by miketrim (guest, #54570) [Link]

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.
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

Posted Feb 12, 2009 1:04 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

The gksu hack seems like it doesn't apply to Red Hat family systems. (Obviously you could manually set sudoers or just give all your users full root privileges, but that's outside the "naive desktop user" concept which seems central to this argument in the first place)

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.

How to write a Linux virus in 5 easy steps

Posted Feb 12, 2009 11:01 UTC (Thu) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

How about saving those kind of Internet files under a owner/group named "internet" which is only able to access the screen and the sound card?
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

Posted Feb 13, 2009 8:12 UTC (Fri) by muwlgr (guest, #35359) [Link] (1 responses)

As well, the desktop environment could keep a list (or database) of known and verified .desktop files together with their content hashes (or even local digital signatures), so for each new/changed .desktop file not included in the list, it should ask the user in most unpleasant and inconvenient way if he/she is aware of what he/she is going to do.

How to write a Linux virus in 5 easy steps

Posted Feb 13, 2009 23:24 UTC (Fri) by mlankhorst (subscriber, #52260) [Link]

and what if you modify a .desktop file by hand? ...