Now to fix archivers [LWN.net]

Now to fix archivers

Posted Feb 26, 2009 11:09 UTC (Thu) by epa (subscriber, #39769)
Parent article: Desktop malware risk gets raised and patched

As the summary points out, you are still vulnerable if you receive a .zip or .tar.gz file by email and your friendly GUI archiver program unpacks it and makes files executable. For command line tar(1) and zip(1) it's fine to extract with the same executable permissions as in the archive*, since command line users can be expected to understand the risks of running executables, and the command line interface doesn't muddy the distinction between opening a file and running it. ('less some_file' versus './some_file')

But for graphical unarchiving programs - or browsing directly to the contents of a zip file inside the file manager - I would prefer that the default be for all plain files to be non-executable, even if the archive specifies that the +x bits be set. If the user wants to extract a zipfile and have executables (or .desktop files) be ready to run by double-clicking, this should require an explicit step, where the app can give a brief warning.

I must say, though, that GNOME's solution of marking .desktop files not in a system directory as 'untrusted' would take care of a good part of this problem. It will no longer be possible to unpack an archive and get a file that appears to be a JPEG image with thumbnail, but is in fact executing an arbitrary command.

(Log in to post comments)

Now to fix archivers

Posted Feb 27, 2009 11:12 UTC (Fri) by hppnq (subscriber, #14462) [Link]

That is like suggesting all candy to be stripped of sugar, instead of telling your kids not to accept any candy from strangers.

Now to fix archivers

Posted Feb 27, 2009 12:07 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

Huh? How do you figure? The OP suggested that when using a GUI, all executable bits should be stripped, which I guess is kind of like removing sugar from all candy, at least if you're a fan of far fetched analogies. But I specifically suggested that this action only be applied to archives that are marked as untrustworthy by the system, e.g. mail attachments. The exact same files that are as of today already stripped of their executable bits in the case of regular executable programs, and soon also for .desktop files, would also be stripped of executable bits even in the case of archives.

Since you're a fan of analogies, that would be like automatically stripping the sugar of all candy that was given to you by strangers. Hardly an ideal way of raising you child if that is the _only_ action you take, but it could be one small part of a balanced strategy aiming to raise your children.

Now to fix archivers

Posted Feb 27, 2009 14:09 UTC (Fri) by hppnq (subscriber, #14462) [Link]

I'm sorry if it was not obvious what I meant to say.

How and when will your system distinguish untrusted archives from non-trusted archives, and, given the fact that a perfectly good reason for putting files in an archive is to preserve permissions, how and when would you or your system restore the original bits?

Oh, and what problem would you have solved? How many times would you be prepared to solve it?

Now to fix archivers

Posted Feb 27, 2009 15:06 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

There are two suggestions for tagging any file as untrusted in the original article: SELinux tagging and having an 'untrusted downloads file area'.

As to when one would restore the original bits, I suggested a dialog for doing exactly that in my original post.

Now to fix archivers

Posted Feb 27, 2009 16:00 UTC (Fri) by hppnq (subscriber, #14462) [Link]

There are two suggestions for tagging any file as untrusted in the original article: SELinux tagging and having an 'untrusted downloads file area'.

These two "tagging" methods indicate that you already know which files are trusted and which files are not trusted. So the question remains.

As to when one would restore the original bits, I suggested a dialog for doing exactly that in my original post.

And I asked the reasonable questions: what problem do you think you have solved, and how many times will you solve it?

There is nothing very insecure about a user downloading or even unpacking an archive -- except of course if you suddenly start to treat certain file attributes, like execute bits or mime types, in a new and special way.

Now to fix archivers

Posted Feb 27, 2009 16:42 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

How many times will this problem be solved? How many times can any problem be solved? At most one, of course. If a problem is solved, it is by definition solved and in no need of being solved. But in this case, it is a superbly silly question that makes me wonder if you understand the reason why we have computer security mechanisms at all. Your question seems to assume that the problem of computer security is a problem with one single solution that will resolve every issue for the rest of eternity. Not going to happen.

The problem that is partially solved is the problem of computer security. Specifically, it slightly improves the security in the situation of an Internet connected desktop computer with a non-experienced user, where it is currently far too easy to use social engineering to infest a great number of machines with trojans because of security policys that currently make it far to easy to run arbitrary executables downloaded from the Internet.

What has been proposed is another partial solution, and I'm sure more partial solutions will be created in the future. It's an endless balance between security and convenience.

Now to fix archivers

Posted Feb 27, 2009 18:23 UTC (Fri) by hppnq (subscriber, #14462) [Link]

I am afraid you do not really understand what I mean. I was asking how many times you expect users to go through what could be easily perceived as a pointless dialog, and what exactly is accomplished by going through this dialog.

Those who believe that we can use the execute bit to indicate a certain level of trust are indeed forced to also take into account previously completely unrelated things, like permissions of archived files. Remember the security problem addressed here is about a kind of file that used to only be meaningful in a desktop environment. By requiring that desktop launchers be actual executables we have not really solved the actual problem at all, but I am all of a sudden stuck with a whole bunch of executables and a security policy that says "You trust all your executables".

There is no dialog on earth that could repair this.

So how would your dialog handle malicious RPM scripts?

Now to fix archivers

Posted Feb 27, 2009 23:43 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

Ok. Rereading your comment, it still seems to me that my interpretation is by far the more natural one. But let's move on.

The simple answer to the question of how many times the question should be asked is simple: As long a no executable file is created, zero. If an executable file is created, the user should be prompted for confirmation once. The exception to this is with .desktop files, for which the prompt is shown when the file is first executed, and not when saved. Preferably, when a user is asked for confirmation and and gives it, the untrusted flag should be stripped; if the file is indeed evil, the damage is already done.

As for evil RPM:s, they are already handled by the package managers of today - packages that are not signed by a known key will not install without an extra override switch.