Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#9881 closed defect (fixed)

Javascript can create/resize windows to consume the entire desktop

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-pref, tbb-fingerprinting, tbb-testcase, tbb-firefox-patch, MikePerry201408R
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Skruffy reports:

04:00 < skruffy> mikeperry: it's possible to steal screen size with making user click some link, so it does window.open(with over9000xover9000 size) or does with resizeto(). If opened with one tab then no need click even.

This is probably too obvious to be regularly used by advertisers, but we should figure out a way to fix it.

Child Tickets

Attachments (1)

stopresizing.diff (551 bytes) - added by cypherpunks 5 years ago.
dom.disable_window_move_resize is true by default

Download all attachments as: .zip

Change History (38)

comment:1 Changed 6 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 6 years ago by mikeperry

window.sizeToContent is potentially another vector for this, and mozilla already introduced clamping for it in https://bugzilla.mozilla.org/show_bug.cgi?id=764240. We may be able to adapt that clamping to apply to other types of resizes, too.

comment:3 Changed 6 years ago by gk

Cc: gk added; g.koppen@… removed
Keywords: tbb-testcase added

comment:4 Changed 5 years ago by cypherpunks

What platforms limiting maximum window size? I know Windows since XP limiting window size, but allowing to bypass restrictions with some tricks.
If no window size limits then no fingerprinting can be done, attacker will request over9000 window and will get it.

Mozilla broken limits for windows even, it happened by fix for https://bugzilla.mozilla.org/show_bug.cgi?id=783333
It's already in current releases and will be in next ESR. Not sure if they wanted that, but it is.

What do you think?

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:5 Changed 5 years ago by cypherpunks

Why to allow window resizing at all? If valid popup then why it should be with different size, why need to create yet one properties to identify users?

To disable resizing need to change dom.disable_window_move_resize to true by default. That's all.

comment:6 Changed 5 years ago by cypherpunks

If valid popup then why it should be with different size, why need to create yet one properties to identify users?

Btw, it's hard to do anyway. Any valid popups will be rounded by Torbutton anyway. Resizing possible with tricks and fraud only. Yet one reason to disable resizing in general.

Changed 5 years ago by cypherpunks

Attachment: stopresizing.diff added

dom.disable_window_move_resize is true by default

comment:7 Changed 5 years ago by cypherpunks

Status: newneeds_review

comment:8 Changed 5 years ago by gk

Keywords: GeorgKoppen201404R added

comment:9 in reply to:  6 Changed 5 years ago by gk

Replying to cypherpunks:

If valid popup then why it should be with different size, why need to create yet one properties to identify users?

Btw, it's hard to do anyway. Any valid popups will be rounded by Torbutton anyway. Resizing possible with tricks and fraud only. Yet one reason to disable resizing in general.

Looking at a bunch of Mozilla bugs (299424, 309251, 328492, 454779...) it seems Mozilla got bitten by that change in the past. While I personally agree with you that resizing the window after Torbutton rounded it properly might be a sign of malicious behavior I may just surf the wrong websites :) That said: What worries me more is disallowing the moving of popup windows. That seems something to me that is not problematic from a fingerprintability perspective, yet it would be forbidden with your patch as kind of collateral damage. And here I can think of useful scenarios, even if i am currently not aware of a site that moves its popups. I need to think about it more and would like to get other opinions.

comment:10 Changed 5 years ago by cypherpunks

And here I can think of useful scenarios, even if i am currently not aware of a site that moves its popups.

To move it need to know where to move, but patches to Firefox code makes it impossible to know about real screen and offset coordinates from point of view of website. It's like to move window about size of all avail space of screen, any moves leaves part of window out of useable screen.
What useful scenarios to move window out of screen?

comment:11 Changed 5 years ago by cypherpunks

Actually I'm worrying about race conditions in between window.open(with height width defined) and resizing of window by Torbutton. Can site to have some information using this races?

comment:12 Changed 5 years ago by cypherpunks

Can site to have some information

Just tested, outerHeight (or any else size) properties just after window.open() returns requested or size to which was limited by platform. Fingerprinting works if size limited. If not limited than that fact leaked too. Fingerprints around.
dom.disable_window_move_resize can't to fix it of course.

comment:13 Changed 5 years ago by cypherpunks

Torbutton rounds window size wrongly, too late and useless.

comment:14 Changed 5 years ago by cypherpunks

Worst thing that it is not even noticeable to user. Fingerprinting can work right now, but rounding by Torbutton hides it.

comment:15 Changed 5 years ago by cypherpunks

Wrong comment. Deleted

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:16 in reply to:  11 Changed 5 years ago by gk

Replying to cypherpunks:

Actually I'm worrying about race conditions in between window.open(with height width defined) and resizing of window by Torbutton. Can site to have some information using this races?

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

comment:17 Changed 5 years ago by gk

Keywords: MikePerry201404R added

comment:18 Changed 5 years ago by cypherpunks

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

This bug is about window.open actually too.
"Javascript can create"

comment:19 in reply to:  18 Changed 5 years ago by gk

Replying to cypherpunks:

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

This bug is about window.open actually too.
"Javascript can create"

Ah, I see your point and it would defeat the currently proposed patch. Good idea. So, are you claiming in comment 12 that this is actually an issue? Do you have some example code to test this hypothesis?

comment:20 Changed 5 years ago by cypherpunks

<html>
<body>

<p>Click the button to open</p>

<button onclick="openWin()">Open Window</button>

<script>
function openWin()
{
myWindow = window.open("","","width=9000,height=9000");
var winW = myWindow.outerWidth;
var winH = myWindow.outerHeight;
alert(winW+"x"+winH);
}
</script>

</body>
</html>

comment:21 Changed 5 years ago by gk

Keywords: GeorgKoppen201404R MikePerry201404R removed
Status: needs_reviewneeds_revision

This test lives on https://people.torproject.org/~gk/misc/entire_desktop.html now. Thanks. We need a new patch then it seems.

comment:22 Changed 5 years ago by cypherpunks

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609:) full-screen-api.enabled = false, that should squash 'em all.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:23 Changed 5 years ago by cypherpunks

Status: needs_revisionneeds_review

Changing status to needs_review because the first pref from comment:22 fixes the window.open() leak

comment:24 Changed 5 years ago by erinn

Keywords: tbb-firefox-patch added

comment:25 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser

comment:26 in reply to:  22 ; Changed 5 years ago by gk

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609:) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted. Hrm, it seems we can't solve this properly with just setting some preferences...

comment:27 Changed 5 years ago by gk

And I still think we should not prohibit moving popup windows. There might be useful applications out there and moving popup windows does not seem to be a fingerprinting vector.

comment:28 in reply to:  26 ; Changed 5 years ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609:) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted.

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

-- faether (sorry, can't open an account due to #12721)

comment:29 in reply to:  28 ; Changed 5 years ago by gk

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609:) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted.

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked. This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

And this still works even though https://bugzilla.mozilla.org/show_bug.cgi?id=565541 got fixed long ago? Do you have a) example code showing this and b) how is this related to the bug at hand?

comment:30 in reply to:  29 ; Changed 5 years ago by faether

Replying to gk:

Replying to cypherpunks:

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked.

Huh. That sounds interesting. Just so I really understand it right,

  1. You started a clean Tor Browser on the test machine,
  2. its initial window had a correctly rounded size A,
  3. you set browser.link.open_newwindow.restriction = 0,
  4. went to the test page from comment:21 and clicked "Open window",
  5. it did not open a new window, but a new tab in the initial window,
  6. but the test still reported size B, with B != A?

If that's the case, can you tell me the test machine's OS etc.? I'd like to reproduce it.

Here (Linux, fresh TBB installation), browser.link.open_newwindow.restriction = 0 causes the comment:21 test to open in a new tab in the main window and to show that main window's size, as it should.

[However, even if browser.link.open_newwindow.restriction = 0 does not work absolutely everywhere, we could still set it to protect most users?]

This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

See, now I'm confused again. When browser.link.open_newwindow.restriction = 0 is set and works, then the window-rounding code shouldn't even fire here because popups will never go to a new window.

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

And this still works even though https://bugzilla.mozilla.org/show_bug.cgi?id=565541 got fixed long ago?

Oh you're right, with browser.link.open_newwindow.restriction = 0 it's unnecessary to add dom.disable_window_move_resize = true. I've been using that latter pref for many, many years and hadn't even realized that things have improved. :)

Last edited 5 years ago by faether (previous) (diff)

comment:31 in reply to:  30 ; Changed 5 years ago by gk

Replying to faether:

Replying to gk:

Replying to cypherpunks:

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked.

Huh. That sounds interesting. Just so I really understand it right,

  1. You started a clean Tor Browser on the test machine,
  2. its initial window had a correctly rounded size A,
  3. you set browser.link.open_newwindow.restriction = 0,
  4. went to the test page from comment:21 and clicked "Open window",
  5. it did not open a new window, but a new tab in the initial window,
  6. but the test still reported size B, with B != A?

Yes.

If that's the case, can you tell me the test machine's OS etc.? I'd like to reproduce it.

It is an old netbook with two slow cores and 1GiB RAM running Debian testing. I did not see the issue on faster hardware. It is probably a race condition in our rounding-window-on-startup-nightmare. See #9268 for the remaining issues and why we need a Tor Browser patch.

[However, even if browser.link.open_newwindow.restriction = 0 does not work absolutely everywhere, we could still set it to protect most users?]

Maybe. So what is your proposed patch for this bug then just doing a browser.link.open_newwindow.restriction = 0?

This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

See, now I'm confused again. When browser.link.open_newwindow.restriction = 0 is set and works, then the window-rounding code shouldn't even fire here because popups will never go to a new window.

I'd need to dig up the code but I think the new-window-logic is running as usual (+ the window-rounding code) but is encountering the request to open the content in a new tab in its course. This happens before the user is seeing anything on its screen. The result is: no popup window but a new tab.

comment:32 in reply to:  31 Changed 5 years ago by faether

So what is your proposed patch for this bug then just doing a browser.link.open_newwindow.restriction = 0?


Yes.

Plus full-screen-api.enabled = false to fix #12609 in the same release, ideally - and then ever onwards towards the next rounds of fingerprintability whac-a-mole... :)

comment:33 Changed 5 years ago by faether

So who do you have to bribe to land these prefs? ;)

Seriously though, now there's TBB 3.6.4 and they're still not in... I'm not saying this to blame anyone, G*d bless y'all, but it feels like even simple anti-fingerprinting fixes are moving very slowly, and I'd be interested in what can be done about that.

comment:34 Changed 5 years ago by mikeperry

Keywords: tbb-pref MikePerry201408R added

This one seems like a decent workaround to me. I am inclined to agree that fixing some instances of this are better than letting it go.

I am a little concerned about the usability of popups going to new tabs, but I think it is not terrible. At least, not as comparatively terrible as #12609's pref suggestion.

Gk - how do you feel about the usability aspects of this?

comment:35 in reply to:  34 Changed 5 years ago by gk

Replying to mikeperry:

This one seems like a decent workaround to me. I am inclined to agree that fixing some instances of this are better than letting it go.

Agreed. Nevertheless, I'd like to have a proper fix for this issue. I'll open a ticket for this once this ticket got fixed by switching the proposed pref.

I am a little concerned about the usability of popups going to new tabs, but I think it is not terrible.

Agreed.

comment:36 Changed 5 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Pref is set. Will appear in 3.6.5 and 4.0-alpha-2.

comment:37 Changed 5 years ago by gk

#12979 is the bug for the real fix.

Note: See TracTickets for help on using tickets.