Trusted vs Unstrusted MIME types

[Patryk Zawadzki]

On 7/8/07, Thomas Leonard <talex5 at gmail.com> wrote:
> On Sat, 07 Jul 2007 16:22:19 -0400, Christopher Aillon wrote:
>
> > Thomas Leonard wrote:
> >> Christopher Aillon wrote:
> [ unsnipped ]
> >>> Why risk a .desktop file which  is wrong?

Desktop files can be as wrong as a MIME metadata. The problem is I as
an author know if my application ever evaluates any part of the unsafe
data (like embedded macros, executing binary parts etc.) while you as
the MIME metadata guard have little to no access to such information
(there are tons of applications that parse certain MIME types).

Paraphrasing your question: Why risk a user who is wrong? If you ask a
user 10 times a day if he desires to open image/jpeg which might be
unsafe, then he is guaranteed to click "yes" when you ask him about
application/x-foo-malware.

I'd propose an additional (and optional) line in Desktop files:
UntrustedData=<Allow|Ask|Deny>

With default being to ask. However the problem is when exactly does
the data become trusted? If Firefox denies to launch a malicious shell
script instead insisting on saving it to desktop, does double-clicking
that new file make it safe all of a sudden?

> My point is, if you think that the application developer / packager will
> incorrectly state that their application is safe*, then they could just as
> easily state that the MIME type is safe too, which is actually worse
> because it affects other programs. Therefore, this isn't a good reason not
> to store this information on a per-application basis.
>
> * <include standard "all-software-has-bugs" disclaimer here>

+1 to that.

> > I'm requesting a list of MIME types known to be potentially unsafe,
> > which already exists in epiphany's source code.  I want each application
> > that needs to use this to not have to keep track of their own list.

Each MIME type is potentially unsafe. Even a simple notepad
application could corrupt your memory due to a buffer overflow in line
processing code. It's the application to decide if it's capable of
having any side effects and thus ALTERING OTHER DATA (due to
evaluation of macros or anything else) while processing this
particular file.

> > You need to understand that security is all about mitigating risks.
> Tagging the types mitigates risk compared to doing nothing, but it
> provides very poor quality information compared with tagging the
> applications, it seems to me. Perhaps I'm misunderstanding what you do
> with this data.

Again, +1.

> >> What would the warning say?
> > In the download manager, the download could be a different color, there
> > could be an icon that would denote its status as potentially dangerous.
> >   Maybe when the user attempts to open from the download manager, it
> > would pop up a dialog similar to what nautilus does when you try to open
> > a shell script:
> >
> > "foo.sh is an executable text file.  Do you want to run foo.sh or
> > display its contents?"

Anything besides text/plain is potentially dangerous. Image and PDF
viewers have a long history of various exploitable overflows. A
flashing GIF file could give you epilepsy and a hard-core pr0n flick
could cause heart attacks on older people.

-- 
Patryk Zawadzki
Generated Content