Closed Bug 1424870 Opened 4 years ago Closed 2 years ago

Clickjacking screenshot taker leads to cross origin info disclosure

Categories

(Firefox :: Screenshots, defect)

58 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: qab, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: sec-moderate)

Attachments

(3 files)

Attached file dndscreen.html
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

I noticed that the screenshot iframes inserted in web can have their CSS changed. By setting their style attribute we can override all its styles. I then noticed that we can take a screenshot of entire website (even things outside its visible body). Finally, I noticed the screenshot preview is data uri which contains all of the data of the screenshot conveniently in base64.

Combining all of the above I think I came up with a pretty convincing PoC.

Video of it in action: https://www.youtube.com/watch?v=De--NcpZofM (note: in the video I use 0.5 opacity for your clarity, it can be lowered to 0 for full effect)


Actual results:

Screenshot of cross origin website is taken unbeknownst to the user, as well as the data grabbed for said screenshot.




Expected results:

I think the simplest solution is to serve the screenshot preview through blob: URI. Then all you are left with is a cross origin blob url which can't be read from any normal web content.
Attached file dnd.html
the helper file required to grab the DnD object. Please host both this and original PoC in the same folder.
Jared, can you or other folks on the screenshots team take a look?
Component: Untriaged → Screenshots
Flags: needinfo?(jhirsch)
Would like to add that even if the preview is changed to blob url, we can still clickjack to the point of having a user later paste the image saved to clipboard. Though that would be less convincing since a notification appears when you choose to copy screenshot. That will alarm more people than original PoC but still something to consider.

Not sure if it's too much to ask to keep checking iframes' style attribute?
I think the plan is to take the UI out of the document entirely, but I defer to Jared and/or other screenshots folks to update the bug with more details (and/or mark as dupe).
Flags: needinfo?(jhirsch)
This bug is a different way of saying it, but effectively is a duplicate of bug 1389707 -- or at least will be fixed by the same fix (bug 1340930).
The ability to muck with the screenshot CSS is known, but reading cross-origin data from the resulting screenshot is a clever twist. Not sure that makes it a different bug but for now I won't dupe it. Changing the results from data: to blob as suggested could be done independently of creating a secure overlay API (and probably much easier).
Depends on: 1340930
Keywords: sec-moderate
Ian filed https://github.com/mozilla-services/screenshots/issues/3508 and has done some work on it.  We should move it into the next sprint.
Attached file dndscreen.html
Although a blob url is being used now, the origin of said blob is same as the potential attacker website and not the webextensions.

Attached PoC requires the old dnd.html helper. WE still end up with base64 data of cross origin website. A fix would require the blob url to have the origin of the extension, and add this url to the manifest file as web content so they are viewable but unreadable.
Flags: sec-bounty?

(In reply to Barry Chen from comment #7)

Ian filed https://github.com/mozilla-services/screenshots/issues/3508 and
has done some work on it. We should move it into the next sprint.

This has been closed because we're discontinuing server uploads in Firefox 67.

Does this mean this is fixed? Based on the descriptions here, I expect not, but I'd love to be wrong...

Flags: needinfo?(jhirsch)

Hmm. Ian, what's the current timeline for screenshots?

Flags: needinfo?(jhirsch) → needinfo?(ianb)

(In reply to :Gijs (he/him) from comment #9)

This has been closed because we're discontinuing server uploads in Firefox 67.

Does this mean this is fixed? Based on the descriptions here, I expect not, but I'd love to be wrong...

It appears to be fixed. The shots UI can still be clickjacked (bug 1389707) but the clever extra bit here of stealing the image contents relied on having the shot URL in the page context which we no longer need to do since we don't upload it. Yes, this screenshotted the attacker's own page, but it could contain 3rd party images or frames that could be interesting to look at.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: sec-bounty? → sec-bounty+
Resolution: --- → FIXED
Group: firefox-core-security → core-security-release
Group: core-security-release
Flags: needinfo?(ianb)
You need to log in before you can comment on or make changes to this bug.