Trusted vs Unstrusted MIME types

[Patryk Zawadzki]

On 7/9/07, Rodney Dawes <dobey.pwns at gmail.com> wrote:
> I didn't say that the user should BE in control. I said the user should
> FEEL in control. There's a big difference there. If the user keeps
> blindly clicking "next" then they aren't in control. They are dismissing
> the annoyances that make them feel as they aren't in control.

Then we agree here.

> > It's not possible inside web browsers and generally any software
> > dealing with remote files (and these are the major threat). Sniffing
> > contents might be either impossible (a large file that is either not
> > fully downloaded yet or not meant to be downloaded at all in case the
> > opening application wants to do it by itself) or very expensive
> > (samba, webdav over Internet).
> Anything is possible if you write the software correctly. We (at least
> in GNOME) already sniff files as they are being downloaded. I would
> rather download only part of a large file that has bad data, than waste
> time for the whole thing, to only later find out it's sending out
> e-mails to everyone in my address book. If we sniff partial downloads,
> we can then pause the download and inform the user of malicious files,
> before everything gets down the pipe, and they trash their system. If
> we just place the choice of fear on the user always at the start of
> download, we will either prevent them from getting the data they want,
> because of fear, or cause them to ignore fear, and just trash their
> system. Either way, the software is to blame.

You sir are right here.

> > The JPEG case needs to be fixed in the application and not in the
> > sniffer. Both would take the same amount of work.
> All cases need to be fixed. But they can't be guaranteed to be. There
> is no way to guarantee that all users have all updates at all times.
> It's just not possible.

And there is no way to make sure that the detection system is up to
date. That's the same problem.

> > I think to solve this properly we'd need a new filesystem with more
> > extended attributes that follow the file (think of "marked as safe")
> There really is no way to solve this properly. You can't know for 100%
> whether something is safe or not, until you run it. The absolute best
> we can do to check for safety, is to sandbox, sniff, and run. If a file
> marked as safe, is written to by a malicious program believed to be
> safe, then the file is no longer safe, even though it is marked as such.
> And presumably to mark something as safe, is something a user must do.
> At that point, you might as well just do nothing. Malicious users will
> mark malicious data as safe, if the meta-data is transferable with the
> file. You then still end up with the problem of having malicious data.

My conclusion was based on the assumption that metadata is not
transferrable via portable media or network sharing (these typically
drop extended attributes and ACLs due to either not supporting them or
extended metadata making no sense out of the context).

-- 
Patryk Zawadzki
Generated Content