This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 733504 - (CVE-2011-3201) CVE-2011-3201 evolution: mailto URL scheme attachment header improper input validation
CVE-2011-3201 evolution: mailto URL scheme attachment header improper input v...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20110825,reported=2...
: Security
Depends On: 757159 757164 885558
Blocks: 733696 855229
  Show dependency treegraph
 
Reported: 2011-08-25 16:10 EDT by Matt McCutchen
Modified: 2015-07-31 10:32 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-05 07:54:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Composer screenshot (40.68 KB, image/png)
2011-08-26 08:47 EDT, Matthew Barnes
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 657374 None None None Never

  None (edit)
Description Matt McCutchen 2011-08-25 16:10:09 EDT
This is another Evolution security issue that I found upstream but presume also affects Fedora and would like to put on the Fedora security team's radar.  If my filing such bugs is not appreciated, please let me know and I will stop.

Description of problem:
Evolution registers a "mailto:" URL handler that accepts a parameter to attach a local file.  Thus, a web site can launch the composer on an email with a confidential file attached and try to trick the user into sending it.

Version-Release number of selected component (if applicable):
Upstream gnome-3-0 branch as of 2011-08-24

How reproducible:
Always

Steps to Reproduce:
1. Go to https://mattmccutchen.net/private/evolution-mailto-test .
2. Click "Send" in the composer.

Actual results:
Your SSH private key is emailed to me.

Expected results:
A prompt is shown and you decline to attach the private key.
Comment 1 Stefano Cavallari 2011-08-26 05:00:22 EDT
I wonder why this functionality exists at all. IMHO the right thing to do is to ignore the "attach" parameter, I can't figure out any use case for that.
Comment 2 Matthew Barnes 2011-08-26 08:47:11 EDT
Created attachment 520081 [details]
Composer screenshot

Nautilus SendTo relies on it.

The exploit is pretty lame in my opinion, since it requires two human errors.  The first is not noticing the suspicious looking ?attach= parameter in the URL, which I can kind of forgive, especially when it's hidden behind innocent looking HTML text.  Similar to phishing schemes.

But the second required human error is not noticing the big attachment icon at the bottom of the composer window while composing the message.  That strikes me as pretty far fetched.  (see attached screenshot)
Comment 3 Josh Bressers 2011-08-26 09:31:57 EDT
I'd call this exploit above lame. Most people don't pay attention to this sort of thing. Granted, those same folks are unlikely to have ssh keys :) But it's still something we should fix.
Comment 4 Josh Bressers 2011-08-26 09:47:30 EDT
Err, not lame. Sorry.
Comment 5 Josh Bressers 2011-08-26 09:55:43 EDT
This goes all the way back to RHEL4. I'm going to move this bug to the security response product so we can begin proper tracking.
Comment 6 Matthew Barnes 2011-08-26 10:48:06 EDT
The ?attach= parameter should be stripped out by the application spawning the mailto: URL handler, not the application receiving the mailto: URL.  There's valid use cases for an ?attach= parameter, as I pointed out above with Nautilus SendTo, which is why nearly all mail clients support it.
Comment 7 Stefano Cavallari 2011-08-26 10:56:10 EDT
> The ?attach= parameter should be stripped out by the application spawning the
mailto:

I'm not sure about that. mailto: is a standard URI, and it should be quite safe to use. If some applications decided to extend the standard and do something not security sensible, it's their fault. 
Browsers should not need to know anything about a (non-internal) URI scheme, beside allowing it or not, and what client to use.
Comment 8 Matthew Barnes 2011-08-26 12:46:36 EDT
Claws Mail has a good solution for this.  It too handles "attach" parameters in mailto URLs, but it checks the file name against a blacklist which includes:

   ".gnupg/"
   "/etc/passwd"
   "/etc/shadow"
   ".ssh/"
   "../"

I think this would be a reasonable compromise for Evolution.
Comment 9 Matt McCutchen 2011-08-26 14:06:14 EDT
(In reply to comment #6)
> The ?attach= parameter should be stripped out by the application spawning the
> mailto: URL handler, not the application receiving the mailto: URL.  There's
> valid use cases for an ?attach= parameter, as I pointed out above with Nautilus
> SendTo, which is why nearly all mail clients support it.

Quoting https://bugzilla.gnome.org/show_bug.cgi?id=657374#c3 :

After the URL handler security model has been ambiguous for so long, assuming
the URLs to be trustworthy or sanitized and obliging all callers to comply is
unrealistic.

(In reply to comment #8)
> Claws Mail has a good solution for this.  It too handles "attach" parameters in
> mailto URLs, but it checks the file name against a blacklist which includes:
> 
>    ".gnupg/"
>    "/etc/passwd"
>    "/etc/shadow"
>    ".ssh/"
>    "../"

Such a list is never going to be complete, so it's hardly a solution.  ".fedora.cert" anyone?

The more interesting point is that Claws Mail has a remote command interface which is unrestricted.  That is the solution for Nautilus "Send To".
Comment 10 Matt McCutchen 2011-08-26 14:12:40 EDT
(In reply to comment #2)
> The exploit is pretty lame in my opinion, since it requires two human errors. 
> The first is not noticing the suspicious looking ?attach= parameter in the URL,
> which I can kind of forgive, especially when it's hidden behind innocent
> looking HTML text.

Or an HTTP redirect, as in my demo.  There is nothing for the user to notice, he/she just has to be willing to visit your web site (same assumption as in most XSS/XSRF attacks).
Comment 12 Ramon de C Valle 2011-11-25 10:49:49 EST
Created evolution tracking bugs for this issue

Affects: fedora-all [bug 757164]
Comment 14 Murray McAllister 2011-12-13 21:41:51 EST
Acknowledgements:

Red Hat would like to thank Matt McCutchen for reporting this issue.
Comment 17 errata-xmlrpc 2013-02-21 05:21:08 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2013:0516 https://rhn.redhat.com/errata/RHSA-2013-0516.html
Comment 18 Huzaifa S. Sidhpurwala 2013-02-21 23:32:47 EST
Statement:

(none)

Note You need to log in before you can comment on or make changes to this bug.