Page 1 of 2

top level built-in pdf.js viewer isn't blocked

Posted: Mon Oct 19, 2015 4:57 am
by al_9x
pdf.js has been exploited, so should be blockable

Re: top level built-in pdf.js viewer isn't blocked

Posted: Mon Oct 19, 2015 5:24 am
by barbaz
i think it uses resource: URIs (well, the extension does, i've never used the firefox built-in version)
try remove "resource:" from the mandatory whitelist (about:config), and whitelist individual resource: URIs like domains instead, if you want to block pdf.js ?
disclaimer: this is not advisable for those who don't know and understand the implications!!!!!!!!!!!!!!

Re: top level built-in pdf.js viewer isn't blocked

Posted: Mon Oct 19, 2015 5:24 am
by barbaz
also, IIUC the exploit is not of pdf.js itself but just using it as a vector for a browser vuln which has been patched in the browser since 39.0.3 & equivalent esr
viewtopic.php?f=19&t=21134

Re: top level built-in pdf.js viewer isn't blocked

Posted: Mon Oct 19, 2015 10:35 pm
by Thrawn
Also bear in mind that the reason PDF.js could be exploited is because it interacts with chrome. If chrome code has weaknesses (as was the case here), then that's beyond NoScript's scope or ability to protect you.

But as barbaz mentioned, you can remove resource: from the whitelist if you really want to.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Mon Oct 19, 2015 11:31 pm
by al_9x
Calling it a vector does not change the fact that simply loading a pdf compromised firefox in a way that a scriptless hml page could not. That is proof enough that pdf.js should still be treated more like a plugin rather than just web content, and therefore be blockable.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 3:34 am
by barbaz
pdf.js is an extension, sometimes integrated in the browser and sometimes not. If pdf.js is to be blocked like a plugin, then by the same argument, every possible extension that interacts 'content' with chrome in any similar way(s) needs to have the 'content' it loads, blocked as a plugin also, due to the same risk of exploit of that vulnerability in older Fx, as it too would be just as much of a vector.
I don't think it's technically possible for Giorgio to implement that, as some said extensions could be totally indistinguishable from browser code from NoScript's perspective, e.g. if they use chrome: URIs instead of resource: URIs. I see no reason that pdf.js should be treated as a special case, and doing so has serious potential to give users of older Fx and another pdf.js-like extension as above, a false sense of security. Yes, pdf.js was exploited in the wild and no other like extension has as far as we know, but in security generally have to assume that there are always possibilities for exploits of a publicly known vuln like this, that have not been realized in the wild, as such blocking just one vector of potentially many doesn't cut it for a preventative tool such as NoScript.

Do you have access to the security bug and thus understand something about this that we don't?


Oh, and if resource: is forbidden (about:config, delete resource: from noscript.mandatory, restart browser, remove resource: from the whitelist), then the following permissions given through the NS menu make pdf.js work:

Code: Select all

+pdf.js
+resource://pdf.js

With the latter not showing up until the former is Temp-Allowed for some weird reason, and manual reloading is required after each permission change.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 4:07 am
by Thrawn
barbaz wrote:pdf.js is an extension, sometimes integrated in the browser and sometimes not. If pdf.js is to be blocked like a plugin, then by the same argument, every possible extension that interacts 'content' with chrome in any similar way(s) needs to have the 'content' it loads, blocked as a plugin also, due to the same risk of exploit of that vulnerability in older Fx, as it too would be just as much of a vector.

Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.

Conceptually it might make sense to treat PDFs as another embedding, except that practically speaking it might not be especially feasible?

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 4:12 am
by barbaz
Thrawn wrote:Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.

Because they're separate things. I don't see the connection here?

Thrawn wrote:Conceptually it might make sense to treat PDFs as another embedding, except that practically speaking it might not be especially feasible?

I would think that probably is feasible... the problem comes when documents other than PDFs are read by other addons that can also be used as vectors for this vulnerability, and those won't be blocked if pdf.js / PDF is given special treatment, making the endeavour somewhat pointless.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 5:14 am
by al_9x
pdf.js is not an extension, it is built in. However since plugins are on their way out, it would be reasonable for mozilla to enable a class of plugin-like extensions for rendering arbitrary mime types. Maybe this already exists, don't know. If/when it does, then noscript's embedding blocking functionality should focus on such extensions, and assuming mozilla designs the api correctly, blocking them all should be the same. In the mean time, pdf.js is a good place to start, it's built-in, has been compromised, and should be blockable.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 7:26 am
by Thrawn
barbaz wrote:
Thrawn wrote:Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.

Because they're separate things. I don't see the connection here?

Well, PDF rendering is a separate thing too. Blocking Flash prevents exploits of privileged code (the binary plugin); blocking PDF would prevent exploits of privileged code (PDF.js). Pretty much the same in concept.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 4:32 pm
by barbaz
al_9x wrote:pdf.js is not an extension, it is built in.

It is an extension whether it's built in or not, basically same thing different look. Please don't take my statements out of context.
barbaz wrote:pdf.js is an extension, sometimes integrated in the browser and sometimes not.

"Sometimes" meaning "in recent Firefox versions, but not in e.g. SeaMonkey".

al_9x wrote:However since plugins are on their way out, it would be reasonable for mozilla to enable a class of plugin-like extensions for rendering arbitrary mime types. Maybe this already exists, don't know. If/when it does, then noscript's embedding blocking functionality should focus on such extensions, and assuming mozilla designs the api correctly, blocking them all should be the same.

Agreed, but I'm pretty sure this isn't there yet. IMO this would be great to include in WebExtensions, but that's another subject.

al_9x wrote:In the mean time, pdf.js is a good place to start, it's built-in, has been compromised, and should be blockable.

I don't follow? It's a totally different thing, the effort involved in this will provide no progress to the effort to block a future "plugin-like extension API".

Re: top level built-in pdf.js viewer isn't blocked

Posted: Tue Oct 20, 2015 4:43 pm
by barbaz
Thrawn wrote:Well, PDF rendering is a separate thing too. Blocking Flash prevents exploits of privileged code (the binary plugin); blocking PDF would prevent exploits of privileged code (PDF.js). Pretty much the same in concept.

Sure but my point is this isn't enough, if NoScript is to even claim to block this type of exploit then NoScript needs to always know when content is interacted with chrome in that way and thus block it before it happens.

Here's an analogy that might help understanding: this is exactly like someone demonstrating an XSS vuln on a site with a PoC that's just a simple alert showing cookie info, and the response is to block only those XSS attacks that are nothing but a simple alert showing cookie info, while leaving all other XSS attacks that were possible, still possible.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Wed Oct 21, 2015 1:59 am
by Thrawn
barbaz wrote:this is exactly like someone demonstrating an XSS vuln on a site with a PoC that's just a simple alert showing cookie info, and the response is to block only those XSS attacks that are nothing but a simple alert showing cookie info

Not quite. Blocking (or having click-to-play) for all PDF documents is much more generically useful. Just like the embedding types.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Wed Oct 21, 2015 2:44 am
by barbaz
Evidently I am still not making myself clear.

Thrawn wrote:Blocking (or having click-to-play) for all PDF documents is much more generically useful.

Well, yeah, but that's useful only as a countermeasure to PDF exploits - but for the vulnerability in question, there's nothing special about the fact that the exploit vector used in the wild is a PDF reader. Therefore blocking PDFs *cannot* dependably pre-empt exploits of this browser vulnerability.


If NoScript does start blocking PDF documents as plugins, that feature cannot claim to even mitigate this vulnerability's effect, otherwise users will have a false sense of security.

Re: top level built-in pdf.js viewer isn't blocked

Posted: Wed Oct 21, 2015 4:44 am
by al_9x
barbaz wrote:Evidently I am still not making myself clear.


You've made yourself crystal clear, let's see if I can summarize.

The latest pdfs.js vulnerability,

https://www.mozilla.org/en-US/security/ ... sa2015-78/
http://www.welivesecurity.com/2015/08/1 ... ay-attack/

is only tangentially and superficially related to pdf.js. Other than the fact that pdf.js is necessary for the the exploit to work, and disabling pdf.js (pdfjs.disabled) disables the exploit, there is hardly a relationship. pdf.js is just one possible vector, the others are innumerable albeit non-existent in stock firefox. The exploit could have been triggered by any one of these many vectors, provided it was pdf.js It is therefore illogical and entirely pointless for NS to block pdf.js as it would merely block this exploit.