Closed Bug 1840265 Opened 11 months ago Closed 11 months ago

Malicious WebExtention can leak history using captureVisibleTab and <all_urls>

Categories

(WebExtensions :: General, defect)

defect

Tracking

(Not tracked)

RESOLVED INVALID

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
Attached file poc.zip

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:

  1. Download and extract poc.zip to a folder
  2. Open the Firefox browser and load the extracted files as WebExtention about:debugging#/runtime/this-firefox to begin testing.
Flags: sec-bounty?
Attached video demo.mp4 (obsolete) —

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.

Component: Security → General
Keywords: privacy
Product: Firefox → WebExtensions

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.

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → INVALID
Flags: sec-bounty? → sec-bounty-
Summary: Malicious WebExtention can leak history using captureVisibleTab → Malicious WebExtention can leak history using captureVisibleTab and <all_urls>
Group: firefox-core-security
Attachment #9340856 - Attachment is obsolete: true
See Also: → 1865101
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: