Re: [Evolution] evolution doesn't seem to handle inlined content securely

[Andreas Wüst <awuest swissonline ch>]

Hi Dan

Thanks a lot for your answer!!

On Mon, 2003-08-18 at 14:40, Dan Winship wrote:

> The fact that iframes are insecure in Outlook is strictly because of an
> Outlook bug. (Well, an IE bug actually, but Outlook uses IE to render
> HTML.) There is nothing inherently insecure about them, and Evo doesn't
> have the same bug,

I.e. attachements are only handled by a viewer and never launched, do
you mean that?

> AND Windows viruses can't infect you on Linux anyway.

Ok, this is not an argument!

> So this is really a non-issue.

So, to sum up what I've learned till now:

If attachements are inlined via an iframe, only a few file types will
get considered, the other file types will just result in an empty frame.
The valid file types are being handled by a viewer.

Only a few types are considered secure and therefore built-in to be
displayed. But others can be configured as well via the user
instransparent gconf interface (i.e. there's no way for the user to
fastly check which file types are being considered). (Think
preconfigured evolution packages.)

Ok, is seems to be pretty secure this way, but I just don't like the
intransparencies of the chosen method. But I know that evolution should
also be easily configurable by the novice, so it seems to be a trade-off
between ease of use and feature-rich configurability, which some of us
like to have.

All in all, it would be nice if there would just be a config option to
turn off automatic display of inlinded content or just any (non-textual)
content (no, not a fully featured text display to replace the html view,
but just an option to turn off the call of any viewer).

> -- Dan
>
> On Sat, 2003-08-16 at 09:38, Andreas Wüst wrote:
> > Hi
> >
> > Thanks for your answer!
> >
> > On Fri, 2003-08-15 at 02:21, Not Zed wrote:
> >
> > > I might also add that this is functionality is absolutely required to
> > > implement html email.  e.g. the introduction email that comes with
> > > evolution.
> > >
> > > Its up to the image library to handle it, so yes you could exploit holes
> > > in libjpeg or gdk-pixbuf if they existed.
> > >
> > > The alternative is to only allow the display of text ...
> >
> > Wouldn't it be possible to use the html rendering widget only for the
> > headers (just to get the nice box), the body of the mail gets displayed
> > using a text box?
> >
> > Since the headers are being preprocessed anyway if you use full html
> > rendering, you could simply reuse the header preprocessor method, and
> > feed the rest of the mail to a text box.
> >
> > I am sorry I can't provide a patch for this., ;)
> >
> > > On Thu, 2003-08-14 at 14:13, Andreas Wüst wrote:
> > > > Hi
> > > >
> > > > Am I right that evolution doesn't seem to do no better than outlook when
> > > > it comes to inlined data?
> > > >
> > > > If you get an email sporting a line like
> > > >
> > > >         <img src="cid:blablabla">
> > > >
> > > > and attached you get a file with a
> > > >
> > > >         Content-ID: blablabla
> > > >
> > > > string, evolution tries to to display this stuff inline, no?
> > > >
> > > > And since most of these attachements are virus today, the user is no
> > > > better off than an outlook user?!
> > > >
> > > > Please correct me, if this isn't so! But, e.g. what happens, when you
> > > > receive an email with an attachment blabla.scr, and the mime type is
> > > > audio/wav, an this file is inlined by the above tag, then evolution
> > > > tries to view (play) it (of course it's not a wav file, just look at the
> > > > file suffix, it's just some viral code)?
> > > >
> > > > There is obviously no button which you could press to view the
> > > > attachement, since it's getting viewed inline. Is there any way to
> > > > prevent evolution from doing so?

-- 
Best wishes,
Andi