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

Bug reports and enhancement requests
al_9x
Master Bug Buster
Posts: 931
Joined: Thu Mar 19, 2009 4:52 pm

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

Post by al_9x »

pdf.js has been exploited, so should be blockable
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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!!!!!!!!!!!!!!
*Always* check the changelogs BEFORE updating that important software!
-
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

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

Post 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.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
al_9x
Master Bug Buster
Posts: 931
Joined: Thu Mar 19, 2009 4:52 pm

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

Post 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.
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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.
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

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

Post 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?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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.
*Always* check the changelogs BEFORE updating that important software!
-
al_9x
Master Bug Buster
Posts: 931
Joined: Thu Mar 19, 2009 4:52 pm

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

Post 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.
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

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

Post 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.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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".
*Always* check the changelogs BEFORE updating that important software!
-
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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.
*Always* check the changelogs BEFORE updating that important software!
-
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

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

Post 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.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

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

Post 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.
*Always* check the changelogs BEFORE updating that important software!
-
al_9x
Master Bug Buster
Posts: 931
Joined: Thu Mar 19, 2009 4:52 pm

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

Post 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.
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0
Post Reply