849357 - Fox19 Native Viewer is subject to abuse

Status: RESOLVED INVALID

(Firefox :: PDF Viewer, defect)

Description

[john]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Use of the native PDF viewer has the potential for abuse.

Sending someone a PDF with documented text, but deliberately using a known annotation method which is known not to be displayed, is, effectively a bug which can be abused in a commercial or other environment, where the expectation is that a viewer -will- display the document correctly.

I can think of a zillion mission critical places, where even accidental non-disclosure of documents' contents would be disastrous -- engineering environments, legal documents tendered to a court or downloaded from a court website, transaction paperwork....the list is endless



Expected results:

DISABLE, permanently, this "feature"

be glad to discuss this with anyone inside Moz-land....

Comment 2

[john]

Not a duplicate.   

There, the problem is that deliberately hidden layers/contents are accidentally exposed.   Here...that intentionally exposed layers are hidden -- this is a critical error where content distribution -is- expected to be seen.

One could -not- say, in such a circumstance, that it was the draftors' fault for using a non-secure environment to hide things.

Court orders, with signatures or amendments.
Design documents bearing notations for change.
Change orders on construction or other contracts.

The expectation is that the content -will- be available to the reader.   Both the author -and- the reader have a shared expectation that the content is embedded, and is readable.

Without that reliance and expectation, the PDF document system fails.  And someone with knowledge of that failure can seed presumptive documents with content that the reader won't know about, but for which the read grants consent.  That such a thing is not possible is the expectation of any static and secure data transport system, which a PDF documents is taken to be, and allowing the current native PDF to exist is a security failure

John Ruskin
BS/MS Engineering, JD

Comment 3

[Matthias Versen [:Matti]]

Let me rephrase your bug report:
You want that the pdf.js feature gets removed again because it contains bugs (as any PDF reader) and some documents may be incorrectly displayed.

bugzilla is a tool for our developers to manage their work on Mozilla.org Products. Bugzilla is not the right place for non-technical discussions and that includes discussions about disabling the pdfs.js feature in Firefox.
That's the reason why I mark this report invalid

some additional comments by me:
We are happy to work on bug reports from you that include an example PDF file that is not working as expected. The pdf.js developers can work on the example PDF in your report and fix the bugs in future versions. A feature like pdf.js can not be perfect from the start but it will get better and better.

The motivation to develop this feature is simple:
The attack vector for many malware infections are either Acrobat Reader or the Java plugin. Both are known to be notorious insecure.
The new PDF feature is a huge security improvement and will protect billions of our users from infections. Any security failure that you have posted is nothing compared to the Acrobat reader security failure.
Google Chrome did the same as firefox but they are doing it in a less secure way with a c/c++ instead of pure JS pdf reader replacement.

Comment 4

[john]

Matthias

I have great respect for your opinion, but I do disagree.  The nature of this viewer has both a security risk, and a separate (and dangerous) bug.  And so, respectfully, I do not concur with your statement about what I would recommend.

The Fox19 native viewer will not display content that both author and reader expect to be there.   The author could never know that the reading person didn't view the document as written, and the reader could never know that the content was there.   This is the raison d'etre for a PDF document.

This is wholly different from a typical rendering bug, where the content is placed in a funny position, or lines get fuzzy.   And, though I don't know what triggers the message, the native viewer does recognize some faults and will temporarily publish a warning.

As an engineer and attorney, I recognize that the software is effectively saying is that no PDF documents' text produced and transmitted to anyone with a Fox19 reader can be trusted to produce the same (text or other) contents to the author and to the reader, -and- that there is no way for either to know that has even happened.  

I accept your perspective that the countervailing risks mitigate in favor of a native viewer, even with security and bug issues.

However, at the very least, the software should not be enabled by default, without notice to the user.  At the very least, when the native viewer puts up an error bar/notice, the error bar should be retained whether or not the reader chooses to use another reader.   At the very least, the warning should be reworded to explain that content may be missing (not merely displayed incorrectly).  At the very least, the warning should print on on any printed copy of the document.  And, at the very least, the fact that the Fox19 native viewer is being used should be described in the tool area (I am a sophisticated computer user -- it took me a while to discover which piece of software or server was rendering what I though were PDFs on a non-local server).

Those missing steps, alone, have humongous implications.   Those "at very leasts" -are- bug reports.

Yes, I concur that the other readers are buggy and have security issues, and I applaud bringing on a native reader.   But for the reasons stated here and at 845650, there is a security hole.

And, I would be glad to provide my test case, though bug 845650 has an example, -and- the native software -already- knows that some contents is display wrong.

Regards,

JR

Out of curiosity, does the Fox19 Native viewer work if JS is disabled ?

Comment 5

[john]

Attachment: Unannotated document

This is a PDF, produced by PDFCreator, no annotation

Comment 6

[john]

Attachment: Annotated document - native viewer does not display document

This PDF has a text box -inside- of which an annotation was added using NitroReader3.   The annotation does not display in the Fox19 native viewer, but does in Acrobat Reader, NitroReader.

Comment 7

[Matthias Versen [:Matti]]

bug 845650 is one example of many other known issues in the pdf reader.
btw: The security issue pointed out by that reporter is IMO nonsense.

That bug doesn't match your report and each single technical problem needs it's own bug report.
It's an explicit decision by the project management to activate the pdf.js feature in Firefox19 and they knew that it's contains bugs. In case that you want to discuss this decision you should use the newsgroups but i doubt that it will change anything.

The general discussion about "pdf.js does many things wrong in many pdf files" is not something that we can use in bugzilla. A bug report is something where a developer can work on a single technical issue.

Please create a new bug report for your testcase. This bug is about "disabling pdf.js again" and it's marked invalid.