1978985 - PDF.js does not enforce PRINT restrictions when permissions are enabled, can be used to strip other restrictions

Status: REOPENED

(Firefox :: PDF Viewer, defect, P1)

Description

[HariHacks]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Firefox for Android

Steps to reproduce:

1. Create a Password Protected PDF file with all permissions disabled — particularly:
   Printing (both low and high resolution)
   Content copying
   Modifying
   Annotations
   Accessibility extraction

2. Open this PDF using Firefox (which uses the integrated PDF.js viewer).
   Enter the user password to view the document.
   Press Ctrl + P (Print).
   Select "Microsoft Print to PDF" as the printer.
   Save the file.

Actual results:

The newly saved PDF is fully unlocked:
You can print it.
You can copy text.
You can edit or annotate it using PDF editors.
All original restrictions (DRM) are completely removed.
This means PDF.js bypasses protection mechanisms meant to limit user actions like printing or extracting content. It directly violates author-specified usage permissions and has serious implications for confidential and rights-managed documents.

Expected results:

Firefox should respect the PDF's permission settings and:
Prevent access to the Ctrl + P (print) functionality if print is disabled.
At a minimum, warn the user that printing/exporting is not allowed.
The output file should retain original permission flags if saved/exported.

Other browsers like Chrome, Edge, and Brave correctly prevent printing when the PDF printing permission is disabled.

I reviewed the relevant source code in PDF.js:
The permission check is handled in https://github.com/mozilla/pdf.js/blob/master/web/pdf_viewer.js
Upon checking the source code in the repository, the file web/pdf_viewer.js contains a function #initializePermissions() that handles some permission flags like COPY, MODIFY_CONTENTS, and MODIFY_ANNOTATIONS, but does not handle the PRINT permission flag.

Comment 1

[Daniel Veditz [:dveditz]]

Why would Firefox want to be complicit in restricting what users can do with PDF content? (Don't mind me, just trying to get the bug to the right folks. Maybe this is a bug rather than intentional)

Comment 2

[Daniel Veditz [:dveditz]]

This may be a duplicate of bug 792816 where by default Firefox does not respect PDF DRM, but there is a pdfjs.enablePermissions pref that can be enabled (primarily so enterprise policies can enable enforcement). A decade later some folks might be reconsidering this stance (see bug 1823372)

But before we rush off and make this a dupe, your last comment said you could find where we honored some permissions but not the PRINT permission. Did you try it? I don't have a restricted PDF handy and telling me to create one requires me to go get software I don't have. Between entering the password and printing did you try copying, modifying, or annotating and were prevented? Or was printing allowed simply because no permissions were respected?

That is, if you

1. open the page about:config
2. change the value of pdfjs.enablePermissions to true
3. perform your steps...

Was copying blocked but you could still print? Or did we respect the printing permission?

Comment 3

[HariHacks]

Attachment: Detailed Explanation Firefox Print to PDF Issue.pdf

Hello Sir, I have attached a report that will make you understand what I what to highlight.

Comment 4

[Daniel Veditz [:dveditz]]

In the attached document HariHacks confirms:

In my case, I explicitly enabled pdfjs.enablePermissions = true and confirmed that some permissions like COPY and MODIFY are enforced — but PRINT is still not respected.

Comment 5

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Disable printing when enablePermission is true and the pdf isn't allowed to be printed (bug 1978985) (#20129)

Comment 6

[Daniel Veditz [:dveditz]]

Adding bounty request per reporter's mail.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for Beta & ESR140 uplift?

Comment 9

[HariHacks]

Yes, I believe this issue could affect enterprise environments that rely on PDF permission enforcement. I’d like to nominate it for Beta and ESR 140 uplift.

Comment 10

[Daniel Veditz [:dveditz]]

[Tracking Requested - why for this release]:
This seems like the kind of feature enterprises would want, so we should add to ESR-140

Comment 11

[Daniel Veditz [:dveditz]]

This is a hidden off-by-default feature so this does not qualify for our bug bounty

Comment 12

[Calixte Denizet (:calixte)]

Attachment: Bug 1978985 - Disable printing when enablePermission is true and the pdf isn't allowed to be printed

Comment 13

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Some user could print an unprintable pdf whatever their company policy is
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Sef-contained and small change
• String changes made/needed: no
• Is Android affected?: yes

Comment 14

[Calixte Denizet (:calixte)]

Attachment: Bug 1978985 - Disable printing when enablePermission is true and the pdf isn't allowed to be printed

Comment 15

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Some user could print an unprintable pdf whatever their company policy is
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Self-contained and small change
• String changes made/needed: No
• Is Android affected?: yes

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/24b3fc5152c6
https://hg.mozilla.org/releases/mozilla-beta/rev/38398e568726

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/45ed42f4092c

Comment 18

[Monica Chiorean]

Issue still reproduces on Win11x64 using Firefox builds: 144.0a1(20250902210651) and 143.0b7(20250901090535). With pref "pdfjs.enablePermissions" set to true, Ctrl+P still opens and user can save the password pdf, although print option is not displayed on screen and on print preview document is cut (as in the attached screenshot). Also I used this tool to set printing and password.
Reopening issue.

Comment 19

[Monica Chiorean]

Attachment: screenshot.png

Comment 20

[Simon Friedberger [:simonf]]

The patch seems to be only modifying the toolbar buttons.

Comment 21

[Mike Kaply [:mkaply]]

There's already to handle printing being turned off for the entire browser. Can it be reused for this?

https://searchfox.org/firefox-main/source/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#448

Comment 22

[Calixte Denizet (:calixte)]

The patch is removing the printing button but it disables the printing itself.
Here in using CTRL+P, it's just printing the content of the page as a "normal" webpage which explains why the toolbar is shown on the screenshot.
Anyway, only the visible pages of the pdf could be print with the UI around, which is more or less equivalent to screenshoting the pdf.
So if you've a pdf with 10 pages, you've to print, scroll, print, ... and the result will have a part of the UI, so the overall result isn't really great and again it isn't worse than making screenshots.

I was aware of this issue, since Rob pointed it while reviewing the patch, I'll write a follow-up asap in order to completely disable printing.

Comment 23

[HariHacks]

Hi Calixte, I would like to know weather the patch has been implemented or not, and kindly let me know if a CVE is getting assigned to this security issue.

Expecting an update from you at the earliest.

Thanks.