webgl readPixels FP entropy

readPixels is not covered by RFP (see https://bugzilla.mozilla.org/show_bug.cgi?id=1428034 ) and using my tests [1], on windows I get entropy. Not sure if unique or just OS.

• Windows 7 32bit 2ba61e7e8e370fdbcefb79456e7e944b060f34289af33732aa6eb75af61ff06c
• Windows 7 64bit ac9aa378cd16219ecbcb6ec46b57d8a484ac8ad61cbe63c810b40fb2c741e7f3
• Windows10 64bit c4ef81818ccaca2c4933f63c45bf5ffaaa7f2233f2761e3c6ba14a9e5cb82c25

It seems to be consistent on Linux, and Mac i have no idea: here's some data

• Mint Cinnamon 32/64bit not supported
• Ubuntu GNOME 5abc446cce2558be83bfe60baeb6dc7ff2a17635057c4612fe835649e7c77329
• Debian GNOME 5abc446cce2558be83bfe60baeb6dc7ff2a17635057c4612fe835649e7c77329
• Mac 10.14 96f2538daa8a0a180f77a13d80ad455a75ae17c5495ce90fa4fd4267cbfd5210

So besides windows OS entropy, theres at least two buckets for Linux?

gk said

Interestingly, I get your macOS one on one of my Linux boxes.

added GeorgKoppen201905 TorBrowserTeam201905R component::applications/tor browser owner::tbb-team priority::very high resolution::fixed severity::normal status::closed tbb-fingerprinting type::defect labels

damnit... [1] ​https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#canvas

gk asked

I wonder what version you tested with in ​https://bugzilla.mozilla.org/show_bug.cgi?id=1428034#c7.

I noticed that on April 12th: https://github.com/ghacksuserjs/TorZillaPrint/issues/28#issuecomment-482406126 and my note says I used 8.5a10.

Replying to Thorin:

gk asked

I wonder what version you tested with in ​https://bugzilla.mozilla.org/show_bug.cgi?id=1428034#c7.

I noticed that on April 12th: https://github.com/ghacksuserjs/TorZillaPrint/issues/28#issuecomment-482406126 and my note says I used 8.5a10.

Great. Do you still remember how you tested that, like did you make sure you disabled click-to-play protection for WebGL? Or did you just take a stock 8.5a10 and went to your website and noted the result?

Stock standard: I never play with the slider, as I'm looking for worst case scenarios. My test was fine (after that I just output the error message for possible better entropy): the difference was panopticlick - edit: https://trac.torproject.org/projects/tor/ticket/30537#comment:5 - since this test relates to that ticket: as I said there, it's no longer reproducable, so Panopticlick must have done some code changes

Replying to Thorin:

Stock standard: I never play with the slider, as I'm looking for worst case scenarios.

Okay, yes, going with the worst case scenario is a good idea. However, using the Tor Browser default was not the worst case scenario fingerprinting-wise which we support (however, I agree, it should have been). The worst case scenario here was someone allowing to run WebGL via click-to-play. That would have triggered this bug already as it is not a new one. In fact, Arthur has even pointed out that issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1422890#c3 a while back.

This bug has a cautionary tale to tell (and hopefully some lessons for us to learn):

1. It's a bad idea to use the security slider for privacy means as it makes the result harder to analyze. I've been holding that opinion for a while now but this bug is a strong example for this problem: It seems in part we relied on WebGL being click-to-play to not escalate an underlying privacy issue (we did not even create a ticket for the readPixels() issue until yesterday). Tests until up to 8.5a11 showed we were good and then 8.5a11 adjusted the security settings for WebGL.

2. We did not file the bug right away to have it on our radar. I guess when working on #16005 (moved) it would have been a good time. Or once https://bugzilla.mozilla.org/show_bug.cgi?id=1422890#c3 came up. There is #26198 (moved) but that would likely not have caught this issue.

3. While we put the final fix out in an alpha which gave 4 weeks for finding this issue, that was not enough. There are tests like https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#canvas and folks are using those frequently, but we should be able to do better here by adding a respective test to our own test suite.

Anyway, here comes a patch for review: bug_30541_v2 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_30541_v2&id=299097102f6f90757e9b10a21ad34e0a11a640f8).

Trac:
Cc: N/A to acat, mcs, brade
Priority: Medium to Very High
Keywords: tbb-fingerprinting-os deleted, GeorgKoppen201905, TorBrowserTeam201905R added
Status: new to needs_review

Also your test shows:

getContext
	2d: supported, webgl: supported, webgl2: supported

But webgl2 shouldn't be allowed.

Replying to cypherpunks:

Also your test shows...webgl2: supported.. But webgl2 shouldn't be allowed.

Thanks. If the browser reports that webgl2 is supported, that's one bit of entropy. I'll double check with some tests and kkapsner (it's his code), opened an issue [1]. This is a browser level API check

What the browser does in a test after that can provide more entropy: e.g error entropy (e.g blocked at a different step of the process: e.g slider settings, click to play, extension interference, etc), or provide a hash

Not sure if meant the API check is flawed, or if TB blocks WebGL2.

[1] https://github.com/ghacksuserjs/TorZillaPrint/issues/37

Replying to Thorin:

Replying to cypherpunks:

Also your test shows...webgl2: supported.. But webgl2 shouldn't be allowed.

Thanks. If the browser reports that webgl2 is supported, that's one bit of entropy. I'll double check with some tests and kkapsner (it's his code), opened an issue [1]. This is a browser level API check

What the browser does in a test after that can provide more entropy: e.g error entropy (e.g blocked at a different step of the process: e.g slider settings, click to play, extension interference, etc), or provide a hash

Not sure if meant the API check is flawed, or if TB blocks WebGL2.

We explicitly set webgl.enable-webgl2 to false to make sure no WebGL2 APIs are accessible.

We explicitly set webgl.enable-webgl2 to false

Thanks. I'll get it fixed in https://github.com/ghacksuserjs/TorZillaPrint/issues/37

Edit: actually, it's worked as advertised on FF69: webgl.disabled and webgl.enable-webgl2

• both enabled: both = supported
• both disabled: both = not supported
• webgl disabled, webgl2 enabled: both = not supported (webgl = master switch)
• webgl enabled, webgl2 disabled: webgl: supported, webgl2: not supported

Note: you don't need to refresh the page, just hit the rerun button

I have not tested TB. Are you sure you're not flipping something in the wrong place?

^^ just to be clear, the booleans of each are mismatched

• webgl.disabled (false = enabled, true=disabled)
• webgl.enable-webgl2(^^ the reverse)

I made sure to use the right combinations

Update: tested TB 32/64bit (8.5) and TBalpha (9.0a1) 32/64bit on Windows (all new vanilla setups), and cannot get webgl2 to say it is supported. This is at default settings. I cannot replicate the issue.

r=brade, r=mcs

The patch from comment:5 looks correct and seems to work (we tested it on a macOS 10.13.6 system). I don't know if this change will break a lot of WebGL sites; my hope is not too many.

Patch looks good to me too, tested on Linux. One small note: you could use nsContentUtils::ResistFingerprinting(aCallerType), which already has the aCallerType != CallerType::System check.

Replying to Thorin:

^^ just to be clear, the booleans of each are mismatched

• webgl.disabled (false = enabled, true=disabled)
• webgl.enable-webgl2(^^ the reverse)

I made sure to use the right combinations

Update: tested TB 32/64bit (8.5) and TBalpha (9.0a1) 32/64bit on Windows (all new vanilla setups), and cannot get webgl2 to say it is supported. This is at default settings. I cannot replicate the issue. Use Windows 10 VM.

Replying to acat:

Patch looks good to me too, tested on Linux. One small note: you could use nsContentUtils::ResistFingerprinting(aCallerType), which already has the aCallerType != CallerType::System check.

Thanks, that's a good suggestions. I've pushed bug_30541_v3 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_30541_v3&id=e462f9d9eb505b5e724ec64a52280c70210cf5eb) to my public repo. And merged/cherry-picked the result to tor-browser-60.7.0esr-9.0-1 (commit e462f9d9eb505b5e724ec64a52280c70210cf5eb) and tor-browser-60.7.0esr-8.5-1 (commit a7422f83dff4a4c58b2a763543d4960ac1b42771).

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Should this have an uplit bug filed?

Replying to cypherpunks:

Use Windows 10 VM.

OK. That makes more sense: see https://github.com/ghacksuserjs/TorZillaPrint/issues/37#issuecomment-497164304 - error entropy is a real thing, I'm quite excited :)

closed

moved to tpo/applications/tor-browser#30541 (closed)