Follow up: How to write a Linux virus [LWN.net]

Follow up: How to write a Linux virus

Posted Feb 13, 2009 8:33 UTC (Fri) by foo-bar (guest, #22971)
Parent article: Follow up: How to write a Linux virus

What is totally unclear is why double-clicking doesn't require .desktop files to have the executable bit set.

Pls don't tell that it's because they are not real executables shell or perl scripts aren't executables either, however if you want to run them without manually specifying an interpreter (which from the user's prospective is similar to double-clicking) they have to have execute permissions.

to post comments

Follow up: How to write a Linux virus

Posted Feb 13, 2009 8:53 UTC (Fri) by roblucid (guest, #48964) [Link] (4 responses)

May be because if people have a .pdf file, they expect it to be opened with a PDF reader, and not need to do any manual specification of an executable. Similarly with HTML, PostScript and media files. There's also ppl installing software packages via a double-click on Desktop.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 9:46 UTC (Fri) by Tuxie (guest, #47191) [Link] (1 responses)

But HTML, PostScript, PDF and media files are content files.

.desktop files should really be treated as scripts because that's exactly what they are. There is no reason at all why someone would ever need to download a .desktop file and doubleclick it.

If such a need comes up though, just wrap it in a .tar.gz and let the user unpack it first, or require the user to right click the file -> properties -> make executable.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 12:55 UTC (Fri) by roblucid (guest, #48964) [Link]

> But HTML, PostScript, PDF and media files are content files.
> .desktop files should really be treated as scripts because that's exactly what they are.

Do I need this feature at all? Sounds like something I would prefer totally disabled. If the DE is allowing scripts to masquerade as content, then it's a bug, and if the DE relies on arbitary code execution scripts to function it appears to me to be poor design.

The problem is, how do you avoid content file formats being extended, with facilities like scripting?

Relying on user's not being gullible to avoid giving execute permission, is of limited value. The real problem goes deeper, hence the discussion of sand-boxing.

The data is tainted, the way to untaint it is via validation by trusted code.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 10:16 UTC (Fri) by forthy (guest, #1525) [Link] (1 responses)

There's also ppl installing software packages via a double-click on Desktop.

Of course. But then they know that they are going to install software by doing so, and they should be prompted by the distribution's system tool to install software. You can one-click install on OpenSuSE, and I think it's save enough. It will pop up an "install software" program, which displays what kind of software it wants to install, and even insist on importing a GPG key. I'm not that happy with this GPG key import stuff - they should have installed a signing chain so that you can trust GPG keys that have been signed by some OpenSuSE master keys, because otherwise, you can only blindly import it.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 13:03 UTC (Fri) by roblucid (guest, #48964) [Link]

I agree with you, and it's made clear what will happen. The lack of any useful way to decide on trust for that key, is a weakness in the one-click install.

So now, we have double-click installing programs into the system, and it's OK, because the stuff is signed, and warnings like entering a password to be root, and a general bside covering warning about trusting repositories is given.

OTOH, we have DE which seem willing to run arbitary code, without any precuations.

making .desktop files executable

Posted Feb 13, 2009 9:38 UTC (Fri) by DeletedUser32991 ((unknown), #32991) [Link] (7 responses)

So how difficult can it be to fix this if you really wanted to? Desktop files would want to have a "#!"-line at the beginning before you mark them executable in order to ensure they don't happen to look like different things in other contexts. This would render them non-compliant with current spec (because comments need to start with "# "), but you could look at a few implementations to see if you get by with it. You also need a generic interpreter that works independent of the DE. Then you need to change the DEs to only honor executable desktop files.
All of this seems not too hard to implement if you really put your mind to it but ranting on and on about it is the real path to go.

making .desktop files executable

Posted Feb 13, 2009 10:02 UTC (Fri) by dlang (guest, #313) [Link]

umm, since lines that start with # are comments, adding a #! line to the top of the file would not make them non-complient.

# indicates comments in bash, perl, and many other scripting languages. they all cope quite nicely with #! in the first line (by having the interpreter executing the file ignore it)

at that point the desktop files could be executables in any language. they no longer need to be their own special thing.

on *nix you can have an executable called foo and with the #! 'magic' all you need to do is to execute it and the correct helper app is called with no ambiguity. you don't have to name things foo.pl, foo.php, foo.py, etc. (in fact naming things with extentions is likely to cause grief in the long run when you want to re-write a script in a different language, but find that everything else that calls that script includes a file extention in the name that they call)

making .desktop files executable

Posted Feb 13, 2009 12:36 UTC (Fri) by bluss (guest, #47454) [Link] (2 responses)

That's not bad news, that's GOOD NEWS!

If # are comments in the spec, that means we can introduce a format upgrade where a shebang line (#!/usr/bin/desktop-launcher) is required, and older implementations will treat it as a comment. Then slowly distributions can enforce the executable + shebang requirement.

It is actually very easy: Introduce the new format, and require it. Then handle backward-compatibility by throwing a warning when double-clicking old-style desktop files, with the option to mark it executable and add the shebang ("Do you truth this launcher? Items downloaded from iternet... It will run '/bin/binary'..", "[ ] don't ask me again", "Cancel", "Launch")

making .desktop files executable

Posted Feb 13, 2009 13:01 UTC (Fri) by madscientist (subscriber, #16861) [Link] (1 responses)

You and dlang are not reading carefully enough. tv said that the spec requires comment lines to start with "# " (that is, sharp-space) not just "#". I haven't read the spec so I can't say myself that's right, but if the latter, you win; if the former, you lose.

making .desktop files executable

Posted Feb 13, 2009 14:26 UTC (Fri) by DeletedUser32991 ((unknown), #32991) [Link]

But I was wrong. Sorry.

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 18, 2009 0:01 UTC (Wed) by dwheeler (guest, #1216) [Link] (2 responses)

I agree, this is a trivially-solved problem. In fact, there's a standard solution, it's just that GNOME and KDE don't use the standard in this case. Shame, shame - that needs fixing.

If a file is an arbitrarily-executable program (as desktop files are), then the system should require that the execute ("x") bit be set before it can be run. Period. It should have a "#!..." prefix at its beginning - so the spec should add that. (If you use #!/usr/bin/env ...., then you can even have PATH redirect, but I digress).

Unfortunately, there will probably need to be some temporary stopgaps while everyone transitions to what they SHOULD have been doing in the first place. As a stopgap measure, the GUI environments could process files specially if they are executable and end in ".desktop". Also, the GUIs might accept any desktop file stored in "/usr/share/applications/", even if its "x" bit isn't set; it requires root privilege to write there anyway, so whoever put the .desktop file there was trusted. That way, the transition is pretty painless; once people have switched over, the stopgaps can be removed.

If you always run a given program to process a given file, then it shouldn't need an execute bit. E.G., a PDF reader or HTML file. Yes, an HTML file might include Javascript, but what the Javascript can do is tightly controlled (by correct implementations). Yes, a PDF reader might have a buffer overflow - but clearly that is a bug in the reader. But .desktop files can include ARBITRARY, UNMEDIATED command lines, which you're EXPECTED to run - that makes them fundamentally different.

Then, merely downloading and saving the file from the Internet does nothing - the user must then set the execute bit. Of course, this presumes that unpackaging GUI programs won't just set the execute bit on programs without giving users a chance to deal with that, but that only requires careful implementation of a very few programs.

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 18, 2009 16:19 UTC (Wed) by hppnq (guest, #14462) [Link] (1 responses)

The only benefit to be had from inspecting an executable bit on an untrusted desktop file, is that it may indicate that the user has taken this action knowingly and on purpose. It seems to me that this is a very wrong assumption, one that should not be made at all.

But it gets worse, I think.

Gnome, and I am sure also KDE, already offers an interface for making files on the desktop executable. Desktop launchers are a special class of files, that only make sense in a desktop environment, and that, alas, can also be put on the desktop. The problem is, and remains also in your proposed solution, that to some users a script that sends out credit card data to some unknown website cannot be distinguished from a picture of grandmother reading the desktop specification bible, and that it will also prove a considerable challenge to these users to determine whether or not to set this executable bit.

The system, of course, does a perfectly good job of recognizing all kinds of files, and would certainly not execute files it does not recognize.

What seems a simple, straightforward solution introduces problems without removing the original problem at all: that a user can be tricked into thinking that file A is actually file B, or that file A is of type C. Your proposed solution for inadvertently running malicious programs is trivially circumvented by promising the naive user that making the file executable -- which you have made a standard action now, because there will be legitimate cases also -- allows her to install the new Tom Cruise screensaver.

Adding insult to injury, now, all launchers are a harmless waste of diskspace if I remove Gnome from my system, but not so in the proposed solution: they would remain executable even after removing the complete desktop environment (as in switching from Gnome to FVWM95) -- unless I of course also removed the new, decoupled interpreter, which would possibly result in many errors with a predictable solution, which opens up a whole new category of security issues. (And I do not just mean that in a few years, it would be like suggesting to remove Python from your system.)

It should be obvious that abusing an existing interface will never lead to a more secure system. The proper solution is suggested here already: let the user explicitly confirm that a certain program is to be run with a specific purpose. This is not a problem that is easily solved, it is much more difficult than it seems.

The proper stopgap, IMHO, is to allow launchers (interpreted as such) only in certain directories, and restrict access to these directories.

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 19, 2009 15:51 UTC (Thu) by dwheeler (guest, #1216) [Link]

Clearly there is nothing that is foolproof. I think the key rule is that "to get the system into an insecure state, you must perform a special, unusual operation that is almost never requested otherwise, one the user would notice." (This is why Vista's whining is useless - it complains too often, training users to ignore it.) I think "setting the execute bit" can and should be a sufficiently "special, unusual operation" that it counts. "Please turn on the execute bit" should be something that normal users DON'T do, indeed, many GUI users wouldn't even know how to do it, and you could CERTAINLY put in a warning before doing it via a GUI. In contrast, "save a file from the web" is something that almost EVERY modern user does, so by itself "saving a file" should NOT subvert system security.

I agree that requiring that .desktop directories be in special trusted directories would work. However, that restriction makes .desktop files fail to work on the actual desktop, which reduces their utility greatly. And really, it seems bizarre that a .desktop file won't work on the desktop :-). But SOME change from the present seems necessary.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 10:19 UTC (Fri) by hppnq (guest, #14462) [Link] (9 responses)

What is totally unclear is why double-clicking doesn't require .desktop files to have the executable bit set.

What is unclear to me, is why this keeps cropping up as something even remotely connected to the problem. Yes, the fact that they are not real executables is extremely relevant, because like it or not, that is what the executable bit is supposed to indicate for all my other files. If the desktop launcher were not a file, it would have the exact same security problem, but we would not be having this discussion.

What the desktop people have assumed, is that launchers do not automagically show up on the panel. And on my system, they never do. I don't double click them, I click them, and they launch something that I put in there.

Icons on my desktop? You bet they have to have the executable bit set, at least on my version of Gnome.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 12:05 UTC (Fri) by foo-bar (guest, #22971) [Link] (4 responses)

They *are* real scripts. Because they can execute arbitrary code.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 13:15 UTC (Fri) by hppnq (guest, #14462) [Link]

These launchers cannot execute arbitrary code. You can click on them of course. Whether something bad happens then is a different problem, and because a DE is nowadays getting more and more capable of turning code into a running process, this does require some attention from developers and users alike.

But, since launchers are not only special files to the DE interpreter, but also files on my filesystem and therefore interpretable by my shells, I prefer them to NOT be ordinary executables, shell scripts, Perl files or anything that can be run outside of the desktop environment.

Note that I am not saying that the typical desktop is a very safe place. Here, the problem seems to be that they can be run from different places within a desktop environment, which is not a brilliant idea. The solution is to keep things more separate: you will really not likely find ls(1) in /home/cracker.

All this, of course, has very little to do with serious security threats and defense mechanisms.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 16:08 UTC (Fri) by jhardin (guest, #3297) [Link] (2 responses)

> they can execute arbitrary code.

Not quite. They can execute arbitrary _command lines_.

Perhaps this is a way to address the problem. Provide a list of the executables that the desktop manager is permitted to start via a shortcut.

"rm" for example would _not_ be on the list. Nor would "bash".

Follow up: How to write a Linux virus

Posted Feb 13, 2009 17:28 UTC (Fri) by bluss (guest, #47454) [Link]

And then what about python? it has to be allowed. Then python -c "arbitrary python code"...

Follow up: How to write a Linux virus

Posted Feb 17, 2009 17:08 UTC (Tue) by gouyou (guest, #30290) [Link]

So no way to make a nice icon that I would double click for cleaning up my environment ... yeah right.

Follow up: How to write a Linux virus

Posted Feb 13, 2009 17:01 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

Yeah. And if you have an interpreter for .desktop files, pointed to by a hashbang line, they will *become* real executables, just like shell scripts or Perl scripts are.

(Without said interpreter, the idea is useless.)

Follow up: How to write a Linux virus

Posted Feb 16, 2009 8:57 UTC (Mon) by aleXXX (subscriber, #2742) [Link] (2 responses)

I think xdg-open can "start" desktop files.

Alex

Follow up: How to write a Linux virus

Posted Feb 16, 2009 10:11 UTC (Mon) by hppnq (guest, #14462) [Link]

Brilliant, it can open www.pentagon.gov as well as /tmp/britney.png.

Follow up: How to write a Linux virus

Posted Feb 16, 2009 20:17 UTC (Mon) by nix (subscriber, #2304) [Link]

Can it? How?

(Anyway, shell scripts cannot be interpreters for other shell scripts:
we'd need an actual binary for this job.)

Follow up: How to write a Linux virus

Posted Feb 13, 2009 12:33 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (1 responses)

This would then be enforced by the application and not the OS.

E.g.: what should happen if you mount /home noexec ?

Follow up: How to write a Linux virus

Posted Feb 13, 2009 13:10 UTC (Fri) by roblucid (guest, #48964) [Link]

Won't it succeed if the interpreter is in /usr/bin like perl for example?

Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)

For ~/bin to work for trad shell scripts and such, you need the file to be opened for processing by the exec-ed interpreter, in another filesystem.