Prevent cross-origin information leakage via range requests

(this is a follow-up to https://phabricator.services.mozilla.com/D91746#3198225)

PDF.js does currently not validate the origin of a PDF response before using it. In web pages, this is not a problem, because unauthorized access is blocked by the same-origin policy. In privileged contexts, such as a browser feature or a browser extension, this can become problematic as soon as it is possible to read content from a PDF file into a web page. Even a unidirectional channel with a binary value (e.g. a boolean yes or no) is enough to read information. With the ongoing work for scripting support (relevant components linked from https://github.com/mozilla/pdf.js/pull/12689#pullrequestreview-549350284), the condition for exploitation is about to be met.

In pages 12 and 13 of https://robwu.nl/s/bugswat2019rw.pdf#page=12, I sketched an attack that abuses Range requests to stitch together responses from different origins to read data across origins, with a proof-of-concept exploit that targeted Chrome / PDFium (CVE-2016-5206).

PDF.js does currently not validate the origins/URLs of responses either - we should do that to prevent a similar attack from happening, at least in the following places:

• https://searchfox.org/mozilla-central/rev/de782976bf97669f1e8edee59e7a2398154efe06/toolkit/components/pdfjs/content/PdfJsNetwork.jsm#84-116
• src/display/network.js

We should determine the origin of the PDF file (e.g. from the first response) and then verify that the origin is consistent (and otherwise reject the response). xhr.responseURL can be used to obtain the final response URL, after all redirections. If fetch is used, response.url has the same information.

If we are concerned about potentially breaking functionality for users, we can start by adding telemetry to see how often the origin of the initial response differs from the origin of subsequent requests, before we start to enforce the new restriction.

[Rob--W]

Just asking, but shouldn’t this include https://github.com/mozilla/pdf.js/blob/master/src/display/fetch_stream.js and https://github.com/mozilla/pdf.js/blob/master/src/display/node_stream.js as well?

Yes. I didn’t enumerate everything, but just some of the examples (hence “at least in the following places”).

[Rob--W]

Disabling redirects is a way to resolve this issue, but only if we are absolutely sure that it is safe to do so.

Unless I’m missing something, I believe this is how chrome fixed it.

That is safe (i.e. not breaking legitimate use cases) IF the PDF resource URL is the final URL. If that is the case, simply blocking redirects can fix this issue.