1761472 - PDF.js Parser differential attack

Status: RESOLVED WONTFIX

(Firefox :: PDF Viewer, defect, P3)

Description

[Toni Huttunen]

Attachment: xfa-differential-attack-test-file.pdf

Background

Portable Document Format (PDF) is a popular file format for presenting legal documents and agreements between parties. The PDF standard encodes documents in an as-printed form which should be portable between systems. In this publication, we introduce a parser differential attack targeting Mozilla PDF.js users. The attack makes it possible to create a malicious PDF document which renders completely different content based on the used reader.

The presentation of PDF files is meant to be independent of the used PDF viewer software, web browser, operating system or existing font-files on the device; they should render identically even through various printer devices. PDF readers attempt to present documents as well as they can, and use as many supported and requested sophisticated PDF ISO Standards and proprietary features as possible.

The original PDF file format is dated and limited, and more ISO Standards have been made to fill the gaps, such as Adobe PDF, Adobe PDF Optimized, PDF/A, PDF/A-2, PDF/A-3, PDF/UA, PDF/E and PDF/X. Of these, particularly interesting is Adobe's PDF 1.7 (ISO 32000-1), which introduces Adobe's Interactive Forms, including JavaScript extensions, AcroForms and Adobe XML Forms Architecture (XFA). Many PDF readers do not render content that is not standardized or contain non-essential sophisticated features.

PDF readers are not identical and do not support the same set of proprietary or other, more sophisticated PDF features. In this write-up, we focus on the Mozilla PDF.js solution, but the overall issue is more general. That is, the PDF readers do not warn the user that the presented content contains features that might not be rendered identically everywhere.

Finding

Mozilla PDF.js is a popular Portable Document Format (PDF) library used in Mozilla Firefox for presenting PDF documents. On 2021-10-02 Mozilla activated PDF XFA form support by default. In practice, PDF.js renders fillable XFA form pages that most other readers do not support - these other readers present a fallback PDF page included as part of the document.

This means that XFA PDF readers and non-XFA-compliant readers can present completely different content out of the same base document. None of the readers alert that the document contains unsupported features, or that some rare PDF features are being used that most readers won't be able to render properly.

Mozilla's PDF Reader PDF.js library changelog states “This release features improved XFA support (enabled by default now),” on v2.11.338 release (Oct 02, 2021). https://github.com/mozilla/pdf.js/releases
Which is introduced in the following commit:

https://hg.mozilla.org/releases/mozilla-beta/rev/b3a0ff6bba57

Products that present XFA content as default (POC=1337)

Mozilla Firefox 98.0.1 (64-bit), latest - 1337
Adobe Acrobat Reader DC (64-bit), 2022.001.20085, Windows – 1337
Adobe Acrobat Reader DC (64-bit), 2022.001.20085 Mac – 1337
Adobe Acrobat Mac – 1337
Wondershare PDFelement – 1337 – PDF editor
pdfjs-2.13.216-dist – 1337
https://mozilla.github.io/pdf.js/web/viewer.html -- 1337 (tested using chrome, edge and firefox)
https://mozilla.github.io/pdf.js/legacy/web/viewer.html - 1337

PDF.js dependents potentially affected, e.g, web apps,

https://www.npmjs.com/package/pdfjs-dist?activeTab=dependents
https://www.jsdelivr.com/package/npm/pdfjs-dist

Products that present a fallback PDF page instead of XFA (but still not warn about unsupported features) (POC=1000)

Apple Finder (file preview)
Apple Preview
Apple Safari
Windows (File preview)
Slack
Slack (Web)
Chromium
Edge
Firefox Daylight 98,2 (8475), iPhone
Chromium extension
https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm

Payload(s)

https://github.com/mozilla/pdf.js/files/7251394/Purchase.Order.pdf
https://github.com/mozilla/pdf.js/issues/14090

Payload offers “The document you are trying to load” page if the reader does not support XFA. This content can be modified, like is done in the invoice document included as an attachment. Document offers 1337 price for XFA readers, and 1000 for others.

Impact

As a result, PDF file can be crafted which displays completely different content, based on whether the reader uses the PDF.js library.

As an example, an attacker could try to inject mutually exclusive pages into document, and hope the various openers are using different readers and see the different context. As an example, an invoice document could attempt to present a contract which will present different amounts to an approving supervisor and accounts payable; in this scenario the approval is made by the supervisor for a low sum, while accounting pays the approved larger fee.

Parser differential issues happen when multiple PDF parsers are used for processing a single document. PDF.js enables embedding a PDF viewer in an HTML page making many popular sites affected regardless the web browser. Websites might present PDF file through PDF.js preview, but the download and opening the file locally leads to an alternative content.

Content previewed and downloaded using Firefox might be later opened using local PDF viewer or printed on paper. Corporate printers might accept PDF files directly, via web interfaces or through the USB stick. Also, a system default PDF viewer might change over time, changing the visible content.

Remediation (for service owners)

Services handling arbitrary PDF files should define a list of supported PDF file format extensions and ensure that the files being accepted are in-line with the requirements. Avoid supporting file formats that cannot guarantee the same content will be visible to all users. Files could also be converted to a simpler format where the same potentially lossy converter handles those special cases and strips them out similarly.

Fix (vendor)

Feature rich readers should provide a compatibility view of the document, rendering the document like a basic PDF reader would do. Basic readers should alert in a situation where the document contains an unsupported feature, and the potential consequences of the suffered document portability situation causes. If all pages can't be rendered, the reader should alert about the issue.

Comment 1

[Toni Huttunen]

Attachment: xfa-differential-attack-edge.png

Comment 2

[Toni Huttunen]

Attachment: xfa-differential-attack-adobe-acrobat-pro.png

Comment 3

[Toni Huttunen]

Attachment: xfa-differential-attack-chrome.png

Comment 4

[Toni Huttunen]

Attachment: xfa-differential-attack-firefox.png

Comment 5

[Toni Huttunen]

Hi, have you managed to reproduce the issue?

Comment 6

[Calixte Denizet (:calixte)]

I understand that an attacker could exploit the fact the pdf rendering is different from a viewer to an other.
But this difference in rendering can be due to a missing implemented feature or just a "bug".
I don't really see what we can do exactly.
:dveditz, do you have any thought here ?

Comment 7

[Marco Castelluccio [:marco]]

The same could also happen with webpages behaving differently depending on some property of the browser (e.g. user agent).

Comment 8

[Toni Huttunen]

I have not seen similar kind of HTML parser differential attacks, but existence of those would not surprise. Anyway, PDFs are seen more appropriate format for presenting and archiving contract documents that must be rendered exactly the same. Instead of making all PDF upload portals vulnerable the reader application(s) should try to solve the problem at once.

Improvement suggestions:

• Feature rich readers should provide a compatibility view of the document, rendering the document like a basic PDF reader would do.
• Basic readers should alert in a situation where the document contains an unsupported feature, and the potential consequences of the suffered document portability situation causes.
• If all pages can't be rendered, the reader should alert about the issue.

btw, is it possible to sign PDF XFA differential documents?

Comment 9

[Daniel Veditz [:dveditz]]

Firefox certainly has, in the past, warned when it encounters documents that had features it could not render; scripts in AcroForms, for example. Doesn't look like we warned about the presence of XFA forms, though (tested in an old Firefox 78.x). Perhaps we trusted that since fallback content can be provided, the document author would provide accurate fall-back for them rather than malicious ones? I'm not sure the folks who made that decision are still around.

If you signed such a document, the evidence of the fraud would be right there in the signed document. Seems like a legally risky way to defraud someone in any jurisdiction with good enough laws to enforced a signed document in the first place. To make things worse, PDF signatures don't always guarantee the document is unmodified, as shown in research from Ruhr University Bochum over the past few years. That's a more fundamental problem!

I see the same presentation in Chrome 100 as I do in recent Firefox.

I do see the incorrect display in Safari, Apple Preview, and old Firefox ESR-78

All browsers on iPhone have to use the built-in browser engine for rendering. It's expected that the iOS version of Firefox displays the same as Safari and not like other versions of Firefox.

Thank you for pointing out these kinds of flaws, which presumably you're going to publish at some point. People have unreasonable faith in consistency of PDF documents and these beliefs need to be deflated. It's just another complex document format, with all the kinds of problems of complex document formats.

Comment 10

[Daniel Veditz [:dveditz]]

Ideally, I'd like to have gone back in time and have Firefox give that warning when it encountered documents with XFA forms. I worry that if we add a warning now that "This documet uses a feature that may look different in other readers" people will interpret that as us saying we can't do it right and stop using our arguably-more-correct reader. We can't make other viewers add that warning (not even our own Firefox on iOS, because the browser doesn't know when the content has that feature or not).

Comment 11

[Calixte Denizet (:calixte)]

From my pov, it isn't only a matter of available features or parser, but a viewer could just have a bug which changes a white square into a transparent one and then an attacker could just add this square on some text which will be shown for a user and hidden for an other one.
And this bug could be in whatever viewer (acrobat itself has some bugs).
So a good warning should be "don't trust what you see" and you can apply it to whatever you want, not only pdfs.

Comment 12

[Toni Huttunen]

Yes, there can be other rendering bugs around even after this issue is fixed. Bugs are bugs, and I would assume most of them would be tackled in the long term. Leaving this issue unfixed would be a conscious choice not to even try.

Sentence "This document uses a feature that may look different in other readers" might drive users away. You could say something like "This document is rendered using XFA forms, which is not supported by many PDF readers. Document may look different in those readers"... even better the reader could show the fallback page in the page list somehow marked as fallback page.

Optimal solution clearly requires coordination between vendors. Is it fine to submit this at least to Adobe (which also supports XFA's)?

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:calixte, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 14

[Toni Huttunen]

Issue was posted one month ago. Is this still going forward? What are the next steps?

Comment 15

[Calixte Denizet (:calixte)]

As Dan said (https://bugzilla.mozilla.org/show_bug.cgi?id=1761472#c10) a warning could be mis-interpreted.
In the past we tackled some infobars with some warning which could be disturbing for users.
:RT, what do you think we should do ?

Comment 16

[Romain Testard [:RT]]

(In reply to Calixte Denizet (:calixte) from comment #15)

As Dan said (https://bugzilla.mozilla.org/show_bug.cgi?id=1761472#c10) a warning could be mis-interpreted.
In the past we tackled some infobars with some warning which could be disturbing for users.
:RT, what do you think we should do ?

Overall I feel like this proposed change would mostly add confusion to readers of XFA forms since there is no way to only show the infobar in scenarios where we know users would open the form using another application:

• infobars inform users about content or browser issues - this potential risk of differential attack if the file is read on different readers does not seem to align with typical use cases for infobars
• most users are unlikely to open this document in another viewer that supports XFA (only Adobe supports XFA and in any case most users just would not open a working pdf in another viewer)
• the scenario is hard of users to understand, the message would likely only bring confusion to users

Should the fix instead be about preventing the possibility for a document to be displayed differently inside different readers that support XFA?

Comment 17

[Toni Huttunen]

(In reply to Romain Testard [:RT] from comment #16)

Should the fix instead be about preventing the possibility for a document to be displayed differently inside different readers that support XFA?

Could PDF.js render XFA and the fallback page both? The fallback page could be presented as a compatibility page of the document. This would be simple, effective and easy to understand for the end users.

Comment 18

[Romain Testard [:RT]]

Prioritizing changes has to strike the right mix of "1 - value for impacted users" and "2 - share of users impacted".
I suggest we close this bug report since we're here in a scenario where 1 is unclear and 2 is very low which makes this bug unlikely to be resolved.

Comment 19

[Romain Testard [:RT]]

Prioritizing changes has to strike the right mix of "1 - value for impacted users" and "2 - share of users impacted".
I suggest we close this bug report since we're here in a scenario where 1 is unclear and 2 is very low which makes this bug unlikely to be resolved.

Comment 20

[Toni Huttunen]

(In reply to Daniel Veditz [:dveditz] from comment #9)

Thank you for pointing out these kinds of flaws, which presumably you're going to publish at some point. People have unreasonable faith in consistency of PDF documents and these beliefs need to be deflated. It's just another complex document format, with all the kinds of problems of complex document formats.

Issue has been published:
https://blog.fraktal.fi/two-faces-of-the-same-pdf-document-17e7a15522a0
https://twitter.com/search?q=url%3A17e7a15522a0&source=post_stats_page

Comment 21

[Romain Testard [:RT]]

Apologies I set the wrong status by mistake in Comment 19