GNOME Bugzilla – Bug 684245
Disable 3rd-party browser plugins
Last modified: 2013-05-07 07:41:50 UTC
From downstream bug report at https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1037669 Evolution now uses webkit for html mail. On launch, it tries to access the google-talkplugin. When looking at a certain messages in preview mode (a google calendar invite), it tries to launch /usr/lib/x86_64-linux-gnu/gstreamer0.10/gstreamer-0.10/gst-plugin-scanner. Interestingly, this is happening even though I have 'Only ever show plain text' configured in Preferences/Mail Preferences/HTML Messages (I do have 'Show suppressed HTML parts as attachments' selected). This suggests that evolution: - would gladly use plugins - that javascript is possibly enabled (for the plugin finder) - that the WebKit HTML renderer is being invoked even though 'Only ever show plain text' is selected Webkit is an immensely powerful renderer and it is being used to render completely untrusted input from anyone who can send an email. We need to make sure that plugins and javascript are disabled and that the renderer is not being used at all when 'Only ever show plain text' is enabled (it could be used to deliver text/plain, but it seems that it is processing the HTML then discarding it). This would bring it in line with Thunderbird's policies. I noticed this because I use AppArmor to confine evolution. Unfortunately in my situation, evolution hung on the message that invoked the plugin finder because the plugin finder failed to launch. I have rules now that will prevent the hang, but evolution isn't handling this error condition gracefully either. This should be considered an important security regression.
(In reply to comment #0) > On launch, it tries to access the google-talkplugin. Would be great if you could provide some pointers (AppArmor log or such). > When looking at a certain messages in preview mode (a google > calendar invite), it tries to launch > /usr/lib/x86_64-linux-gnu/gstreamer0.10/gstreamer-0.10/gst-plugin-scanner. > Interestingly, this is happening even though I have 'Only ever show plain text' > configured in Preferences/Mail Preferences/HTML Messages (I do have 'Show > suppressed HTML parts as attachments' selected). I don't see the relation between calendar invitations and having HTML enabled or not. > Webkit is an immensely powerful renderer and it is being used to render > completely untrusted input from anyone who can send an email. We need to make > sure that plugins and javascript are disabled JavaScript is disabled in EWebView: http://git.gnome.org/browse/evolution/commit/?id=967b238b77c1912c33e1a508781d9124b9e351a7
Correct, plugins are enabled according to https://mail.gnome.org/archives/evolution-list/2012-September/msg00055.html
Should it not be possible to limit the use of plugins to only the one(?) that is needed to render the attachment bar?
Tomas is working on a fix which will disable all 3rd-party plugins.
Created attachment 239457 [details] [review] Disable installed 3rd party plugins in WK
Created attachment 239459 [details] [review] Proposed patch Same patch as previous, but with some code style changes. Actually WebKit will be still loading all installed plugins, but it won't be using them.
Review of attachment 239459 [details] [review]: Looks good, please commit to master and gnome-3-8 branches, after the hard code freeze.
Commited https://git.gnome.org/browse/evolution/commit/?h=gnome-3-8&id=875bf4ad9a94df2759039d702606e7f0c8eaf26f https://git.gnome.org/browse/evolution/commit/?id=39e453466544e239ae63f7fadadf2d4e6141f3ca
Hi. This commit introduced a double-free for me: evolution in free(): error: chunk is already free 0x18a65dd62880 (gdb) bt full
+ Trace 231795
(In reply to comment #9) > This commit introduced a double-free for me: > evolution in free(): error: chunk is already free 0x18a65dd62880 That's weird, because the code change is all correct, according to the documentation, unless your webkit version changes API semantic in some way. What is your webkitgtk3 version, by the way?
(In reply to comment #10) > What is your webkitgtk3 version, by the way? Bah sorry, I forgot to mention the obvious indeed :) webkit 2.0.0
I did change this slightly from Tomas' original commit. Details are in my commit message: https://git.gnome.org/browse/evolution/commit/?id=eb6ecc6fb5d1b6859fab949ba20865d2ca784306 But I'm not seeing any problems here. Maybe it's a misbehaving WebKit plugin?
libgnome-shell-browser-plugin.so > But I'm not seeing any problems here. Maybe it's a misbehaving WebKit plugin? The only plugins I had were the ones from gnome-shell and rhythmbox: libgnome-shell-browser-plugin.so librhythmbox-itms-detection-plugin.so I removed them, but same thing... Hmm.
I suspect the misbehaving webkitgtk3 too, or some misplaced unref. Tomas is using the same version as you, with no problem (as far as I know). Could you try to install run evolution under valgrind, whether it'll show where the pointer was removed? You can do that with a command like this: $ G_SLICE=always-malloc valgrind --num-callers=50 --track-origins=yes \ evolution Either the valgrind will crash and print info about the memory (where it was freed), or it'll identify the issue and will run evolution (in a veeery slow mode, dure to all the memory checking).
(In reply to comment #14) > I suspect the misbehaving webkitgtk3 too, or some misplaced unref. Tomas is > using the same version as you, with no problem (as far as I know). Could you > try to install run evolution under valgrind, whether it'll show where the Unfortunately, valgrind is not available on OpenBSD :-/ I'll try and dig up a bit more so that I can provide you guys with more information. Thanks.
OK, thanks. I would try g_object_weak_ref() on each object of the GSList, but it'll not work, if the plugin is already released.
The only free() call in webkit_web_plugin_finalize() is for the priv->path string. Perhaps the private struct is not zero-filled on initialization, and the path string is never set. The address being freed could be garbage. Instance initialization looks like: plugin->priv = new WebKitWebPluginPrivate(); plugin->priv->mimeTypes = 0; But "plugin->priv->path = 0" is conspicuously absent. If I'm right, Tomas can submit a one-line fix for WebKitWebPlugin.
As long as we're talking WebKitGTK+ patches, an even better option would be to disable the WebKitWebPluginDatabase itself, such that it would refuse to load plugins and yield empty results for its lookup functions. That would require new APIs though. It's kinda silly to load all the WebKit plugins only to disable them all. Better to just not load them.
(In reply to comment #18) > Better to just not load them. Or rather, prevent WebKit from loading them.
(In reply to comment #17) > The only free() call in webkit_web_plugin_finalize() is for the priv->path > string. Perhaps the private struct is not zero-filled on initialization, and > the path string is never set. The address being freed could be garbage. > > Instance initialization looks like: > > plugin->priv = new WebKitWebPluginPrivate(); > plugin->priv->mimeTypes = 0; > > But "plugin->priv->path = 0" is conspicuously absent. > > If I'm right, Tomas can submit a one-line fix for WebKitWebPlugin. Hi Matthew. Good catch, adding this line in the initialization fixed the issue for me. I still have some double frees from time to time but they are unrelated to WebKit. Can you contact the WebKit devs regarding this, or should I post a bug report myself? Thank you.
Cool. I'll defer to Tomas to get this upstreamed.
Pushed into WebKit - https://bugs.webkit.org/show_bug.cgi?id=115624