Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#18390 closed defect (not a bug)

PDF.js triggers canvas fingerprinting warning for some PDFs

Reported by: xcolour Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm seeing the canvas fingerprinting warning for some PDFs served by PDF.js in the latest version of the Tor Browser Bundle (5.5.2). It appears that this only happens with image-heavy PDFs.

For example: https://www.aclu.org/foia-document/some-key-sso-cyber-milestone-dates-fall-2005.

It looks like this was fixed in #10570 for the Firefox-local version of PDF.js, but (perhaps intentionally) not for PDF.js if it's being served by the website.

We use the PDF.js provided via the "PDF" Drupal extension version "7.x-1.6" with PDF.js version "1.1.215".

Is this a bug in Tor Browser's canvas fingerprinting detection, or is what PDF.js is doing simply indistinguishable from a fingerprinting attempt?

I've also opened a ticket with the PDF.js team (https://github.com/mozilla/pdf.js/issues/7026).

Thanks!

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 4 years ago by cypherpunks

Resolution: not a bug
Status: newclosed

Replying to xcolour:

It looks like this was fixed in #10570 for the Firefox-local version of PDF.js, but (perhaps intentionally) not for PDF.js if it's being served by the website.

Naturally. Tor Project developers can only vouch for the code they ship, not whatever any random website pushes to you.

Is this a bug in Tor Browser's canvas fingerprinting detection, or is what PDF.js is doing simply indistinguishable from a fingerprinting attempt?

It is indistinguishable because fingerprinting is (potentially) what the site is doing. Tor Browser cannot guess "intent" so it has to be conservative and block access to canvas.

It's not a bug. Tor Browser is doing what it's supposed to do.

Now, if the pdf.js guys are willing to workaround it, they could try to avoid looking "into" the canvas: no getImageData, no to{Blob,Url,File,...}, etc.

comment:2 Changed 4 years ago by xcolour

That's what I figured. I appreciate the quick reply!

comment:3 Changed 4 years ago by cypherpunks

How about substituting site-hosted pdf.js with builtin one in an iframe?

comment:4 in reply to:  3 Changed 4 years ago by cypherpunks

Replying to cypherpunks:

How about substituting site-hosted pdf.js with builtin one in an iframe?

This is interesting. Maybe NoScript surrogates would be enough?

Interesting I said, but I actually do not like idea. You would be running privileged code in an unprivileged context. Need a refresher on privilege escalation exploits? How about these 2:
https://www.mozilla.org/en-US/security/advisories/mfsa2015-69/
https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/

That's a High and a Critical vuln, according to Mozilla's classification, in pdf.js in the last what 6-7 months? The second one was found in the wild:
https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

I think in Tor Browser we should prefer security over convenience. And what kind of inconvenience are we talking about here? This is not Tor Browser outright blocking all canvas code. Is presenting a prompt, in some accesses, and you could dismiss it as well.

In this case, if you decide to disallow it (the finer choice), what's the impact? yurydelendik tells us in https://github.com/mozilla/pdf.js/issues/7026#issuecomment-188802006: "it will affect the display quality for some old windows machines". Who the hell cares? :)

comment:5 Changed 4 years ago by xcolour

Thanks for the feedback!

For our site, we're investigating whether there's a good way to use native pdf-viewing functionality by default, and only falling back on site-hosted pdf.js if there isn't a native option.

The iframe idea is definitely interesting, but I'm not sure I understand your point about privilege escalation. Tor browser already trusts built-in pdf.js (as of #10570). Are you suggesting that was a mistake or something else?

The pdf.js team has also been pretty receptive to working around their use of getImageData et al., but it doesn't look like it's going to be completely straightforward since they use it in a few different places.

Finally, I got a chance to dig into the Tor browser code that's triggering the canvas warning. It's a far simpler check than I thought, and I think it's clear that Tor browser is doing the right thing here, so the onus is definitely on us.

Thanks again!

Note: See TracTickets for help on using tickets.