Bug 733504 (CVE-2011-3201) - CVE-2011-3201 evolution: mailto URL scheme attachment header improper input validation
Summary: CVE-2011-3201 evolution: mailto URL scheme attachment header improper input v...
Status: CLOSED ERRATA
Alias: CVE-2011-3201
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20110825,reported=2...
Keywords: Security
Depends On: 757159 757164 885558
Blocks: 733696 855229
TreeView+ depends on / blocked
 
Reported: 2011-08-25 20:10 UTC by Matt McCutchen
Modified: 2019-06-08 18:54 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-03-05 12:54:57 UTC


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0516 normal SHIPPED_LIVE Low: evolution security and bug fix update 2013-02-20 21:29:11 UTC
GNOME Bugzilla 657374 None None None 2019-05-22 06:35 UTC

Description Matt McCutchen 2011-08-25 20:10:09 UTC
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 09:00:22 UTC
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 12:47:11 UTC
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 13:31:57 UTC
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 13:47:30 UTC
Err, not lame. Sorry.

Comment 5 Josh Bressers 2011-08-26 13:55:43 UTC
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 14:48:06 UTC
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 14:56:10 UTC
> 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 16:46:36 UTC
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 18:06:14 UTC
(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 18:12:40 UTC
(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 15:49:49 UTC
Created evolution tracking bugs for this issue

Affects: fedora-all [bug 757164]

Comment 14 Murray McAllister 2011-12-14 02:41:51 UTC
Acknowledgements:

Red Hat would like to thank Matt McCutchen for reporting this issue.

Comment 17 errata-xmlrpc 2013-02-21 10:21:08 UTC
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-22 04:32:47 UTC
Statement:

(none)


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