Werent we talking about trojans on Linux?
Ingo Klöcker
kloecker at kde.org
Tue Oct 29 00:40:51 GMT 2002
-----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-----
More information about the kde-core-devel
mailing list