Malicious WebExtention can leak history using captureVisibleTab and <all_urls>
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: fazim.pentester, Unassigned)
References
Details
(Keywords: privacy, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Attachments
(1 file, 1 obsolete file)
988 bytes,
application/x-zip-compressed
|
Details |
Using a combination of launching a tab with multiple href links and captureVisibleTab() function, an attacker could capture and leak the history of the victim using a malicious Web Extension. Instead of logging it to the WebExtention , an attacker could also use the XMLHttpRequest() function to send the data to a remote host.
Steps to Reproduce:
- Download and extract poc.zip to a folder
- Open the Firefox browser and load the extracted files as WebExtention
about:debugging#/runtime/this-firefox
to begin testing.
Reporter | ||
Comment 1•11 months ago
|
||
Comment 2•11 months ago
|
||
A malicious extension is bad news. Even with no explicitly requested permissions an extension has powerful abilities that a web page does not. In this case captureVisibleTab()
requires the scary <all_urls>
permission (in Firefox), which gives you more than enough access to be thoroughly evil and silently spy on everything the user does. Noisily creating a new tab so the user knows you're spying on them seems less bad than what can already be done. Of course this gets the attacker immediate results rather than having to gather it over time, if that's worth the cost of revealing themselves.
I'll let the Web Extension folks chime in, but I rather suspect this is "working as expected".
Somewhat tangential context:
Just this past week the W3C Web Application Security group discussed a proposal from Google to prevent remaining timing attacks on :visited history in web pages. It's a "partitioning" proposal that limits the knowledge available to the web site's context and would also prevent visual attacks like the one in this bug if we extended it to extension pages (not guaranteed that we would, but we should). Internally at Mozilla we've previously discussed different partitioning/isolation proposals to address this problem so I'm optimistic we can come to an agreement and get something like this into browsers. It was an early discussion, no promises. We'll talk more at TPAC in September. [Mentioned purely for information; future plans are irrelevant to whether this is a current vulnerability in the web extension APIs or is expected behavior given the permissions.]
Likewise, history links are a potential privacy risk when you share a web page with the Screen Capture API in WebRTC. In that case the user has granted permission to the web page and has selected the window to share themselves, but may not have thought about what is revealed. I've heard horror stories about over-sharing in video conferencing apps (standalone executables, not a problem unique to WebRTC) where people share a desktop or browser window that reveals NSFW or otherwise embarassing titles and images. While worrying about that sort of thing people may not have the headspace to worry about what link colors might reveal.
Comment 3•11 months ago
|
||
The bug title:
Malicious WebExtention can leak history using captureVisibleTab
should have been
Malicious WebExtention can leak history using captureVisibleTab and
<all_urls>
... at which point it is obvious that the bug is invalid. When a user grants the "Access your data for all websites" permission to an extension, then the user cannot expect their information in websites to be private.
Updated•11 months ago
|
Updated•11 months ago
|
Reporter | ||
Updated•10 months ago
|
Description
•