Hello folks
Today we introduced a new validation mechanism for message attachments which are supposed to be displayed inside the browser. Mainly inspired by a recently reported XSS vulnerability [1], the mime-types and filenames extensions stated in the message part headers are now checked against the real mime-type of the effective part bodies. This also requires the filename extension (e.g. ".png") to match the real mime-type of the according attachment.
In order to reliably detect mime-types and the matching filename extensions, Roundcube and PHP need to be configured properly:
On PHP >= 5.3, we recommend to set
$rcmail_config['mime_magic'] = null;
which lets the fileinfo module of PHP use its default location for the magic numbers mapping file.
The other config option which is important for these new checks is
$rcmail_config['mime_types'] = '<path-to-apache-config>/mime.types';
This value should refer to the mime.types file used by the Apache web server to send the right mime-types for static files. If left empty, Roundcube will search for it in some default locations such as /etc/httpd/mime.types but for performance reasons, it's better to set this option right away. In case you can't find such a file on your server, especially when not running apache, you can download it from [2].
Now, with the new attachment validation in place, your users might see some yellow warnings (see attached image) because sometimes email messages are just incorrectly formatted even if all the contents are safe. Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases.
Cheers, Thomas
[1] http://trac.roundcube.net/ticket/1488828 [2] http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
Am 27.11.2012 18:08, schrieb Thomas Bruederli:
Hello folks
Today we introduced a new validation mechanism for message attachments which are supposed to be displayed inside the browser.
I can't figure out what "today" exactly means. I'm currently using "Roundcube Webmail 0.9-git [GIT 20121127.1959]", does this version already contain this mechanism?
If so, it doesn't work for me:
Now, with the new attachment validation in place, your users might see some yellow warnings (see attached image) because sometimes email messages are just incorrectly formatted even if all the contents are safe. Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases.
Unlike before, with IE8 on Win7/64 I can't display your attached image "rcmail_attachment_validation_warning.png" inside the browser anymore. Clicking on the "show" link throws a warning in IE8 (see attached).
After clicking this bar and selecting the option "Datei herunterladen" (= Download file), I get the typical Win7 download dialogue (see attached).
After clicking on "Öffnen" (= Open) I get a safety warning (see attached).
After clicking on "Zulassen" (= Allow) the PNG is displayed in the "Windows-Fotoanzeige". :-(
I don't like that. ;-) How can we get the previous behaviour back, where images could be displayed inside the browser with just one single click...?
Strange: I can display all images attached to my previous post quoted below inside the browser with a single click and without any warning.
But why not the "rcmail_attachment_validation_warning.png" attached to your (Thomas') post?
On 11/27/12 16:17, Michael Heydekamp wrote:
Strange: I can display all images attached to my previous post quoted below inside the browser with a single click and without any warning.
But why not the "rcmail_attachment_validation_warning.png" attached to your (Thomas') post?
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs. Trying to test Roundcube by running whatever git is current when you update may be a waste of time. I do understand the value of trying to test and evaluate an upcoming release early, but I've found that it works best to wait for an identified beta release rather than trying the moving target of git versions.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
On 11/28/2012 01:41 AM, Arne Berglund wrote:
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs. Trying to test Roundcube by running whatever git is current when you update may be a waste of time. I do understand the value of trying to test and evaluate an upcoming release early, but I've found that it works best to wait for an identified beta release rather than trying the moving target of git versions.
Arne, you're of course right. However, this is a developer mailing list and we discuss new features here. We can't do this not using git-master version ;).
On Nov 28, 2012, at 8:07 AM, "A.L.E.C" alec@alec.pl wrote:
On 11/28/2012 01:41 AM, Arne Berglund wrote:
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs. Trying to test Roundcube by running whatever git is current when you update may be a waste of time. I do understand the value of trying to test and evaluate an upcoming release early, but I've found that it works best to wait for an identified beta release rather than trying the moving target of git versions.
Arne, you're of course right. However, this is a developer mailing list and we discuss new features here. We can't do this not using git-master version ;).
I use a separate documentroot and hostname for a git-master clone. Come to think of it, I should just auto-fetch/merge it :)
Cor
On 11/27/12 23:07, A.L.E.C wrote:
On 11/28/2012 01:41 AM, Arne Berglund wrote:
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs. Trying to test Roundcube by running whatever git is current when you update may be a waste of time. I do understand the value of trying to test and evaluate an upcoming release early, but I've found that it works best to wait for an identified beta release rather than trying the moving target of git versions.
Arne, you're of course right. However, this is a developer mailing list and we discuss new features here. We can't do this not using git-master version ;).
Exactly so. That is the purpose, the devs do need this, no other way around it. But for testing by potential end users, it is too much of a moving target. I'll admit that I do pull down a git-master copy now and then to see where things are going, but I don't expect it to be bug-free, or even feature-complete. It's just a snapshot. I confine serious testing to betas and release candidates.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 28.11.2012 08:07, schrieb A.L.E.C:
On 11/28/2012 01:41 AM, Arne Berglund wrote:
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs. Trying to test Roundcube by running whatever git is current when you update may be a waste of time. [...]
Arne, you're of course right. However, this is a developer mailing list and we discuss new features here. We can't do this not using git-master version ;).
Especially, as Thomas explicitely asked for feedback in his announce of this new function:
Am 27.11.2012 18:08, schrieb Thomas Bruederli:
Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases.
Then feedback is given, and being declared by somebody else as a waste of time. Funny...
Am 28.11.2012 01:41, schrieb Arne Berglund:
On 11/27/12 16:17, Michael Heydekamp wrote:
Strange: I can display all images attached to my previous post quoted below inside the browser with a single click and without any warning.
But why not the "rcmail_attachment_validation_warning.png" attached to your (Thomas') post?
Just a thought here. It has been my experience that development builds (via git or subversion) are constantly changing, frequently works in progress, and often full of bugs.
Right. And it is my task - in accordance with Thomas BTW - to identify most of those bugs BEFORE they make their way into a beta or release version. Not a too bad idea, I'd say, as you and all others will encounter less bugs in the next beta or release.
One of the reasons is that I'm using Roundcube as my only MUA. Therefore I will hit those bugs earlier and more likely than any of the developers will do, as they are mainly using other MUAs such as Postbox, Mozilla etc.
Trying to test Roundcube by running whatever git is current when you update may be a waste of time.
Well, it's my time that I'm wasting, and my free decision. Above all, I don't see it as a waste of time.
The issue in the message I'm referring to is resolved in the meantime (an IE8 bug with regards to the filename of the attachment, now being workarounded by Roundcube, thanks to A.L.E.C), but now I've got another one:
Just for testing purposes, I created a message with an ".eml" attachment (checking if it would be declared as "message/rfc822", but due to some reason we still need to figure out on our server, it has been declared as "text/plain").
If I click on this attachment, I get the yellow warning Thomas described in his initial message. First of all, the message is confusing:
WARNING! This attachment is suspicious because its type doesn't match the type declared in the message. If you do not trust the sender, you shouldn't open it in the browser because it may contain malicious contents.
Expected: text/plain (.eml); found: text/plain (.asc)
Hmm, why a warning then, if text/plain is both expected and found...? And where does this "(.asc)" come from?
But more important: If I click on the button "Show it anyway", nothing happens. Really nothing (the window stays as it is, the attachment is not being displayed, as often as I click on that button). The only thing I can do (and that will work) is to close the window.
IE8 and Win7/64.
So:
Am 27.11.2012 18:08, schrieb Thomas Bruederli:
Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases.
Feedback above. ;)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 28.11.2012 01:11, schrieb Michael Heydekamp:
Am 27.11.2012 18:08, schrieb Thomas Bruederli:
Hello folks
Today we introduced a new validation mechanism for message attachments which are supposed to be displayed inside the browser.
I can't figure out what "today" exactly means. I'm currently using "Roundcube Webmail 0.9-git [GIT 20121127.1959]", does this version already contain this mechanism?
If so, it doesn't work for me:
Now, with the new attachment validation in place, your users might see some yellow warnings (see attached image) because sometimes email messages are just incorrectly formatted even if all the contents are safe. Clicking the button will let the user see the attachment anyhow but since this is all new, we're seriously interested in your feedback and common problems resulting from this new check. I hope we can then fine-tune it a bit and catch some common and harmless cases.
Unlike before, with IE8 on Win7/64 I can't display your attached image "rcmail_attachment_validation_warning.png" inside the browser anymore. Clicking on the "show" link throws a warning in IE8 (see attached).
After clicking this bar and selecting the option "Datei herunterladen" (= Download file), I get the typical Win7 download dialogue (see attached).
After clicking on "Öffnen" (= Open) I get a safety warning (see attached).
After clicking on "Zulassen" (= Allow) the PNG is displayed in the "Windows-Fotoanzeige". :-(
I don't like that. ;-) How can we get the previous behaviour back, where images could be displayed inside the browser with just one single click...? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev