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