GNOME Bugzilla – Bug 337439
mail containing mail email addresses DoS
Last modified: 2014-12-02 01:07:25 UTC
Steps to reproduce: Alan Cox discovered a bug in the way Evolution displays a mail message with lots of email addresses in it. A bug has been filed in the Red Hat bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183680 This message: http://zeniv.linux.org.uk/~alan/destroy-evolution.mbox contains many email addresses. It seems that evolution wants to render the numerous mail addresses as links, which will eat vast quantities of memory. Evolution will eventually be killed via an OOM condition. The biggest problem with this issue is that Evolution tries to reopen the message after a crash, rendering the mail reader unusable until the message is manually removed. Stack trace: Other information:
I can NOT confirm this, as mentioned in the original report. When displaying that mail, Evo kept my machine busy for like 30 seconds, maybe a minute. Evolution did not crash, neither was it killed. However, Evolution used about ** 500 MByte ** Resident Memory (addditionally, due to displaying this mail). The memory was free'd after closing Evo. (Not directly after switching to another mail, though I did not use that memory hog for long after that brief test.) Evolution was usable and I can could read the mail in question. Scrolling occupied a lot of resources, though. Rendering is GtkHTML, not Evolution. Cc'ing Harish. FWIW, I have heard about this before, IIRC. And GtkHTML is not particularly smart, resource-friendly or usable with large text mails anyway -- which is a poor, but well known fact.
well, at least when i tested this more than a month ago, evolution did not respond for more than 15 minutes. so i can confirm this.
I just tried this on 3.11.1, and it took ~1 minute and ~650MB of RAM. I'd say this would DoS your system pretty hard if you had <512 MB of RAM. I don't have such a system handy at the moment.
Yes, this will DoS evolution and the system with <512 MB of ram. The real problem though is that evolution tries to open the last viewed message after such a crash, which means one has to muck around in the .evolution directory to run it again.
Josh: No, to prevent rendering of the mail, you can disable the preview pane and set the message display to 'source', which will display the raw message. Disable the preview pane: $ gconftool-2 --set /apps/evolution/mail/display/show_preview --type bool 0 Display the raw source message: $ gconftool-2 --set /apps/evolution/mail/display/message_style --type int 2
also see bug 343424, bug 273171, and bug 271295
Created attachment 76744 [details] [review] Proposed patch
Created attachment 76745 [details] Screenshot
With this patch, before rendering with GTKHTML the message is seen for a limit to render with. Currently it is kept at approx 4MB. You can increase/decrease with the env variable EVO_MAX_TEXT_SIZE . If the message size exceed the limit it displays a inline warning and gives the option to view as plain text or view with an external viewer. [See the attached screenshot] It wont fix just this, all issues with displaying long mails/huge text. I can push this to HEAD but not to stable as it breaks the freeze. I'll ask for freeze break request, and try to push to stable too.
How long does showing it unformatted take? If it's not too much of a burden, I'd say it's better for the user to show it unformatted and give the option to open an external viewer ('This message is too large for Evolution to show with formatting. You can use another application to view it.') It would mean the user doesn't have to click a button just to see what the message is.
Joachim, for this mail it is hardly few seconds. But it shouldnt be the default option. Also, when viewing unformatted, it is inside a text area and not directly under GtkHTML widget. Ill put a screenshot how this will be seen.
Created attachment 76748 [details] Viewed unformatted inside a text area under GTKHTML
Do you mean it's very quick to show it in plain? (Sorry, English has a funny way of sometimes meaning the opposite of what you say -- a native speaker could say 'hardly a few seconds' to mean LOTS of time ;) If that's the case, why not remove the 'Hide' button, and show it like the screenshot by default? If the user is happy with the unformatted version, you've saved him having to click a button to read the message. If the user wants to see it formatted, you've not cost him anything. Perhaps this text would be clearer: 'This message is shown in plain text because it is too large for Evolution to display formatting. Open it in another application to view it with formatting.'
when I load it, it downloads it, puts into a stream. this takes few seconds (10-15). You can even click "View unformatted" it just grows in the scroll bar. But it is contained inside a GtkTextArea widget in GtkHTML which also has scroll bar. It will be annoying to have it visible all the times as there are 2 scrollbars 1-GtkHTML and 1-GtkTextArea. Scrolling sucks there. So it cant be default and also without a button.
Created attachment 76752 [details] repaint issue repaint rendering issue, this goes away after switching window focus to another window and back to evolution. suse 10.1 here.
Created attachment 76776 [details] [review] Updated patch
This updated patch provides an option to set the limit in Edit->Preferences instead of a ENV variable. Most importantly it fixes a bug that andre pointed out and another issue where the headers are not visible in MessageSource view.
*** Bug 378478 has been marked as a duplicate of this bug. ***
I have commited to HEAD and it should be part of 2.9.x
can we close this now?
Sure. Thanks for reminding.
Hrm, I'm not sure the root problem has been addressed here. The issue as I understand it is with GtkHTML's massive memory consumption when rendering HTML containing a large number of URLs. Alan Cox commented in the downstream bug, "The perfect variant of this attack can screw you totally in a good deal under 4MB of input." The option added to Evolution seems like a quick-and-dirty workaround to me and does not fully address the DoS vulnerability. Has there been any investigation of or improvements to GtkHTML's memory management issues?
Matthew, To answer the GtkHTML stuff, currently there is no positive progress towards the memory management improvements. So Just to avoid the DoS, the hack was added. I agree to the point the root problem is not addressed, if you prefer to keep this bug open till the issue is removed from GtkHTML, Im OK towards that.
Strange. With this patch if I set in preferences window 8000 kb message (less than twice big) evolution starts to render full message and eats about 66% of 1Gbyte memory... Can anybody reproduce this? Currently I can't say this solution works here. Another issue is that evolution does not free memory somewhere, thus all 66% stay in memory untill I close application... but this is another bug, I think.
Reopening until the GtkHTML memory management issues are addressed.
*** Bug 339135 has been marked as a duplicate of this bug. ***
Since version 3.6, Evolution uses WebKit instead of GtkHtml for displaying messages. (And for completeness, Evolution 3.14 is planned to use WebKit also for composing and editing messages so GtkHtml will not receive any fixes anymore.) Hence I am closing this GtkHtml rendering bug report. We are sorry that your request was not handled in time when it was reported but unfortunately manpower is very limited (and does not allow testing every single reported issue separately again either). Please feel free to reopen this report (and move it to the "Evolution" product and the "Mail" component) if the problem described in this bug report still happens in a recent supported Evolution version which uses WebKit (the current stable Evolution version is 3.12).