-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 October 2002 00:34, Karl-Heinz Zimmer wrote:
> On Tuesday 29 October 2002 00:26, Karl-Heinz Zimmer wrote:
> > On Tuesday 29 October 2002 00:05, Rinse de Vries wrote:
> > > Hi,
> > >
> > > just received a mail  l in kde-i18n-doc with the following link:
>
> http://www.dilbert.com/comics/dilbert/desktop_diversions/images/dilbe
>rt_screensaver.zip
>
> > > When pressing this link, KMail automagicly opens 'ark' and starts
> > > downloading the compressed file, without any warning...

KMail executes the following code when an URL is clicked:
=====
    KMimeType::Ptr mime = KMimeType::findByURL( mUrl );
    if (mime->name() == "application/x-desktop" ||
        mime->name() == "application/x-executable" ||
        mime->name() == "application/x-shellscript" )
    {
      if (KMessageBox::warningYesNo( 0, i18n( "Do you really want to 
execute"
        " '%1'? " ).arg( mUrl.prettyURL() ) ) != KMessageBox::Yes) 
return;
    }
    (void) new KRun( mUrl );
=====

As you can see we already ask when the user clicked on some programs. We 
should probably change this blacklist to a whitelist, i.e. instead of 
showing the warning for files with a few given insecure mime-types we 
should show the warning for all files except those with a secure 
mime-type. As text/html is also insecure (because it might contain 
malicious Java, JavaScript, Plugins, etc.) we would have to show this 
warning each time a user clicks on a simple HTML link in an email. Is 
it really worth annoying the user with this warning just because 1 in 
1.000.000 HTML pages contains malicious code? Should we add a don't 
show again checkbox? If yes, then why show the warning at all when the 
user can turn it off. The don't show again config entry should depend 
on the mime-type so that the user can decide for each mime-type 
separately whether he wants to be warned in the future or not.

BTW, currently we only get the mimetype by URL which means anyone could 
sell us an executable as JPEG image with name bomb.jpg. KRun would 
realise that this isn't a JPEG image and would then probably run 
bomb.jpg. As you can see protection has to be built into KRun and not 
into KMail so that KRun can be configured to only executes 
trusted/secure/whatever files.

> > > Now what if this was not a zip file, but an .exe file, and I have
> > > Wine installed, would kmail call wine and start downloading the
> > > 'possible virus' without any warning?

KMail doesn't call wine. KRun calls wine.

> > > Now that is a security hole, isn't it?

Yes. But not in KMail. The underlying infrastructure, i. e. KDE or even 
the OS has to handle this.

> > Having thought about it again: No, this should not happen.
> >
> > KMail is not allowed to start WINE without telling you before -
> > that's how it is coded.
>
> Ahem, it is night here and my brain will fall asleep soon: forget it,
> what happens when you click on this link is NOT controlled by KMail
> but by the viewer itself.
>
> So the big question is: Why the hell does the viewer start a download
> if it is not an image that's downloaded?
>
> IM(not so)HO this _is_ a security issue and must be investigated!

Done. It can't really be fixed in KMail since KMail doesn't know the 
real mimetype of the file a link points to but only the mimetype which 
the filename indicates (which is in general completely bogus in case of 
virusses). KRun or a subclass of KRun, e. g. KRunSecure, has to be 
secured against running potentially dangerous programs without warning 
the user.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9vdkZGnR+RTDgudgRAmsIAJ9WKIPFXIIk+7cWFy4CnYK/7/zSTQCglMSk
3uUiASj27ps7mvUxxfJNkoI=
=zW7z
-----END PGP SIGNATURE-----