Bug 733504 (CVE-2011-3201)

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.

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)

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.

Err, not lame. Sorry.

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.

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.

> 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.

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.

(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".

(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).

Created evolution tracking bugs for this issue

Affects: fedora-all [bug 757164]

Acknowledgements:

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

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

Statement:

(none)