Created attachment 8612311 [details] index.html User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.0.1 Build ID: 20150526223604 Steps to reproduce: 1. Open the attached file in the browser. 2. Select a text in any window running in the same X11. (Not tested under Wayland or other alternatives, but it might also work with them.) 3. See the two “links” on the page. Consider them as interesting and open them in a new tab using middleclick. (You don't want to close the article you are reading, do you?) If you don't have middle button on your pointing device, you likely can emulate it by simultaneous clicking left+right button. This emulation can be however disabled. 4. Open the developer console and see the log. Actual results: There was an invisible text field over the link. When the you middleclicked the link, you actually pasted the text you selected in the another app in step #2 without noticing it. For a proof, you can see the text in log of browser's developer console. Note that the two “links” are technically slightly different and browser support varies. Expected results: The browser either just opened the links (and did nothing else) or revealed to user that these links are not just links… ## Details Users are often not aware of the second clipboard functionality in the X11. Even if they are, they are very unlikely to notice that middleclicking outside text input can reveal some sensitive information. Such attack might be practical to deploy on a MITM basis to all plain-HTTP pages through a public Wi-Fi or through a TOR exit node to get some information what users are researching, copied user's passwords, private links, e-mail addresses and so on. I don't think is is possible to mitigate such attacks just by disallowing transparent text inputs, as one could also come with a different technique: A text input styled as a link. User is unlikely to be able to distinguish between a link and a styled text input unless the capabilities of CSS were drastically reduced. So, it seems that a secure browser can't support both middleclick-a-link and paste-by-middleclick features. ## Confidentiality notice This is a multi-vendor issue. Following vendors are contacted at roughly the same time: * Mozilla * Google * KDE * Opera Other vendors may be added. I know that some of browsers do share the rendering engine, but I am not sure if the issue lies in the rendering engine itself. I will not publish details until all the vendors fix the issue or until deadline, whichever comes first. I might, however, make some public comments on the vulnerability even before that if such vulnerability was published by someone else. I aks you to behave the same – even if you have the vulnerability fixed, other vendors may not have it fixed at the same time. The deadline is on 2015-08-26 (UTC), that is after 90 days. It might be postponed by up-to-14-days grace period if some of vendors has prepared a patch within the deadline and scheduled the release within the 14 days after the deadline.
Dave: any thoughts from the front-end owner on how to reconcile this abuse of us using the same click-combo to mean different things in different contexts?
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
Whiteboard: Multi-vendor issue, embargo until 2015-08-26
I believe this was filed previously as bug 405620.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 405620
You need to log in before you can comment on or make changes to this bug.