top level built-in pdf.js viewer isn't blocked
top level built-in pdf.js viewer isn't blocked
pdf.js has been exploited, so should be blockable
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0
Re: top level built-in pdf.js viewer isn't blocked
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!!!!!!!!!!!!!!
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!
-
Re: top level built-in pdf.js viewer isn't blocked
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
viewtopic.php?f=19&t=21134
*Always* check the changelogs BEFORE updating that important software!
-
Re: top level built-in pdf.js viewer isn't blocked
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.
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.
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
Re: top level built-in pdf.js viewer isn't blocked
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
Re: top level built-in pdf.js viewer isn't blocked
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:
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.
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
*Always* check the changelogs BEFORE updating that important software!
-
Re: top level built-in pdf.js viewer isn't blocked
Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.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.
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.
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
Re: top level built-in pdf.js viewer isn't blocked
Because they're separate things. I don't see the connection here?Thrawn wrote:Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.
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.Thrawn wrote:Conceptually it might make sense to treat PDFs as another embedding, except that practically speaking it might not be especially feasible?
*Always* check the changelogs BEFORE updating that important software!
-
Re: top level built-in pdf.js viewer isn't blocked
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
Re: top level built-in pdf.js viewer isn't blocked
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.barbaz wrote:Because they're separate things. I don't see the connection here?Thrawn wrote:Of course, on the other hand, NoScript does deal with embeddings and WebGL separately.
======
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.
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
Re: top level built-in pdf.js viewer isn't blocked
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.al_9x wrote:pdf.js is not an extension, it is built in.
"Sometimes" meaning "in recent Firefox versions, but not in e.g. SeaMonkey".barbaz wrote:pdf.js is an extension, sometimes integrated in the browser and sometimes not.
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: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.
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".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.
*Always* check the changelogs BEFORE updating that important software!
-
Re: top level built-in pdf.js viewer isn't blocked
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.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.
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!
-
Re: top level built-in pdf.js viewer isn't blocked
Not quite. Blocking (or having click-to-play) for all PDF documents is much more generically useful. Just like the embedding types.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
======
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.
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
Re: top level built-in pdf.js viewer isn't blocked
Evidently I am still not making myself clear.
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.
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.Thrawn wrote:Blocking (or having click-to-play) for all PDF documents is much more generically useful.
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!
-
Re: top level built-in pdf.js viewer isn't blocked
You've made yourself crystal clear, let's see if I can summarize.barbaz wrote:Evidently I am still not making myself clear.
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