noscript blocks pdf.js on firefox nightly

[herom]

firefox has added internal support for viewing pdf files using a javascript engine named pdf.js on nightly.
but since the javascript code is injected into the page, noscript blocks the pdf viewer for every pdf file until javascript is allowed for that website.

[Tom T.]

Here is Giorgio's blog post on the pdf.js add-on.

Alternatives include the very lightweight (4 MB) Foxit reader, which integrates automatically with Fx, and reads both web and hard drive pdf's.
Using that, I can open Web-based pdf's *without* allowing script on the site (or in the reader, a huge safety advantage).

Since the add-on is indeed running scripting on a page element, it's not surprising that script must be allowed at that site.
Perhaps Giorgio can provide some means of allowing script from the reader, but not on the site.
If there's an identifiable internal source for the add-on's JS, perhaps ABE might work?

Until Giorgio is available, if you're familiar with ABE, perhaps try that? If unfamiliar, ABE FAQ.

[Giorgio Maone]

This can be safely regarded as a bug (a security bug, to some extent) of the pdf.js implementation.
Here's the report against their original Github repo, it probably needs to be mirrored on Mozilla's bugzilla now...

[herom]

we can probably wait to see if it gets fixed by pdf.js developers, but if it doesn't, this will affect noscript users & their security;
they might allow all scripts on a (possibly malicious) website just to view a pdf on the website.
isn't there any easy way for noscript to detect the pdf viewer's script and let it through?

[Giorgio Maone]

isn't there any easy way for noscript to detect the pdf viewer's script and let it through?

No, because it's completely blended in the page's own scripts.
It's really an unfortunate design choice, which could be worked around in many ways but only in the pdf.js code.

[Tom T.]

I read the bugzilla thread. At the risk of sounding like a broken record, Foxit reads pdf's directly from the Web even without allowing scripting in either the web page or in Foxit. And with *everything* checked on NS Embedding tab, including "Apply to whitelisted sites".

One still needs a pdf reader for desktop pdf's, so I had a hard time understanding why this (redundant) capability was introduced in the first place.

If the pdf is malicious -- presumably via JS -- then with scripting disallowed in both browser and reader, it's hard to picture a successful exploit.

[Giorgio Maone]

If the pdf is malicious -- presumably via JS -- then with scripting disallowed in both browser and reader, it's hard to picture a successful exploit.

PDF is quite a complex format, and parsing it from native (C/C++) code is prone to bugs like buffer overruns and other memory management issues which can be successfully exploited with no scripting involved.
Writing the parser in a garbage collected, memory-safe language (such as Java or, in this case, JavaScript) suddenly removes this whole class of vulnerabilities from the landscape (despite the bad reputation these specific languages deserved for entirely different reasons), and this was the sense of my blog post in reply to Security Hulk's tweet.
Of course, performing the rendering task in the same security context of the hosting site or, even worse, in the chrome context (like very early pdf.js versions) opens the door to other classes of vulnerabilities, which would be avoided if this was done in a sandboxed context like suggested by myself and others in the bug report (with the added benefit of not depending on NoScript permissions).

[Tom T.]

Of course, performing the rendering task in the same security context of the hosting site or, even worse, in the chrome context (like very early pdf.js versions) opens the door to other classes of vulnerabilities, which would be avoided if this was done in a sandboxed context like suggested by myself and others in the bug report (with the added benefit of not depending on NoScript permissions).

Thanks for elaborating, and for confirming my gut reaction to the add-on as presented. It's unfortunate that they didn't take your advice from the beginning. Sounds like they need to start all over again.

JOC, is it possible to create a JS-based pdf reader for the desktop, in such a fashion as you describe, and would it then be safer than (IIUC) all existing C/C++ readers?

Any ways to enhance the safety of of an existing lightweight reader like Foxit, with JS and all other active content already disabled, other than enabling DEP/NoExecute bit (done years ago)?

[Giorgio Maone]

JOC, is it possible to create a JS-based pdf reader for the desktop, in such a fashion as you describe, and would it then be safer than (IIUC) all existing C/C++ readers?

Yes, it's certainly possible by reusing the existend pdf.js rendering code and run it from a single-purpose browser instance, either Gecko or Webkit based.

Any ways to enhance the safety of of an existing lightweight reader like Foxit, with JS and all other active content already disabled, other than enabling DEP/NoExecute bit (done years ago)?

You could run it inside a sandbox, I guess.

[therube]

the very lightweight (4 MB) Foxit reader

Foxit has long passed the "very lightweight" stage. It is not a pig, like Adobe, but it is no longer that (essentially) single .exe program. (Looks like Foxit 2.2 was 5 MB, & Foxit 4.3 was 11 MB. I believe that was the last of the single .exe versions. Current, v5.1, weighs in around 35 MB, spread over a multiple file/directory tree. I've never used its browser plugin myself.)

Foxit reads pdf's ... without allowing scripting in either the web page or in Foxit.

Foxit (as does Adobe Acrobat Reader) has an option to have JavaScript enabled or not. Don't recall what the default setting is?
(In Foxit, Tools | Peferences | JavaScript.)

[Tom T.]

JOC, is it possible to create a JS-based pdf reader for the desktop, in such a fashion as you describe, and would it then be safer than (IIUC) all existing C/C++ readers?

Yes, it's certainly possible by reusing the existend pdf.js rendering code and run it from a single-purpose browser instance, either Gecko or Webkit based.

Ahh, so it can't be a stand-alone. Seems more trouble than it's worth.

Any ways to enhance the safety of of an existing lightweight reader like Foxit, with JS and all other active content already disabled, other than enabling DEP/NoExecute bit (done years ago)?

You could run it inside a sandbox, I guess.

Yes, all Web browsing is sandboxed, and while I don't ordinarily open pdf's from untrusted or unknown sources, Sandboxie can do that, too. I have done that for Word docs from non-tech users, just because they have no idea how many malwares their machine has.

Sounds like I've done the most possible, thanks.

Foxit has long passed the "very lightweight" stage. It is not a pig, like Adobe, but it is no longer that (essentially) single .exe program. (Looks like Foxit 2.2 was 5 MB, & Foxit 4.3 was 11 MB. I believe that was the last of the single .exe versions. Current, v5.1, weighs in around 35 MB, spread over a multiple file/directory tree. I've never used its browser plugin myself.)

I use an older version, 2.0 that has *no* native JS support. -- the 4 MB one.
When I open a pdf with interactive fields, it says a component is missing (the JS parser, undoubtedly), and should I let it go to the Web and get it? I say no, and the doc opens fine, and the interactive fields still work.

Sorry to see that they've gone the bloatware path, like everything else. (sigh)
What is the alleged "benefit" of the 35-MB one?

I've never needed the browser plugin. I get to a Web pdf, click it, dialog box: Open with Foxit? Save to disk? Cancel?
Opens just fine.
So what's the "advantage" of the browser plug-in?

[dhouwn]

Should be fixed now as of Firefox 17. (see also the bug tracker entry Giorgio linked to)

(This was the thread I was searching for all the time, but posted it into the other ones first)