71–80 of 277 posts
Firefox's 'About' page seems to lack enough information here. My page just said 'Firefox 39 available' and 'restart to upgrade'. But the exploit page notes that you need version 39.0.3 in order to be protected. So it's unclear if the upgrade would fix things or not.
Once you've updated, the About Firefox modal will show you the exact version number you're on.
Out of curiosity, how many users will be opening pdf using pdf.js? Is it widely used? I was never comfortable with pdf.js and changed the setting to use the default pdf viewer in all my machines.
I uninstalled PDF viewers and always use pdf.js to view PDFs these days.
Most of the times, I have multiple pdf files open side by side. So I had a pdf viewer in the machine.
Earlier quoted context omitted.
Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.
Docker is not secure enough (it can help but it's not designed to be bulletproof). MAC (GRsecurity...) can be considered the "right" solution. Or just give up and go QuubeOS ;)
Obviously docker, as opposed to Qubes, won't stop more complex malware that exploits the kernel.
Edit: NVD does list a bunch of vulnerabilities with "PDFium" in them [1], and I guess there are a few more from when it wasn't called PDFium yet, but I'm curious as to how an expert would interpret these numbers.
[1] https://web.nvd.nist.gov/view/vuln/search-results?query=pdfi...
Once again, this demonstrates that blocking advertisements is a really good idea from an InfoSec perspective. Ad blocking not only abates a nuisance, it's an important security measure. cf https://twitter.com/swiftonsecurity/status/62840155490772582...
Earlier quoted context omitted.
Instead of $ firefox you start $ docker run mozilla/firefox and get instant process isolation and protection from these kinds of exploits. Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowle…
It appears that since we're discussing this on a page related to a firefox issue of exactly that nature that this approach is insufficient.
>> The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.
Moreover, since it seems you believe that javascript is a liability in this case (as much as I loathe the language: it's not!)
be aware that you still need to interpret javascript to read all of the pdfs you can find:
http://mariomalwareanalysis.blogspot.co.uk/2012/02/how-to-em...
(I also remembe reading something about opengl embedded in pdf, but I cannot find it anymore)
The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively. Would like to know if an installation is vulnerable if: 1) If Applications, PDF is set to "Always ask" 2) Ublock and/or privoxy are used 3) Javascript is disabled 4) pdfjs.previousHandler.alwaysAskBeforeHandling == false 5) pdfjs.disabled == true Also which advertising network and which Russ…
Hi, I reported this 0-day. It used a PDF.JS same origin policy violation to access local files. You should be safe because you have javascript disabled and pdfjs.disabled set to true. There's no way for the script to run. It was on a international news website operating from Russia. The exploit was not on an ad network. The exploit was simply injected on every news article page through an iframe. Therefore I assume t…
Earlier quoted context omitted.
You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should…
I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight b…
In addition to that, I am very glad that Chrome and Firefox ship with their own PDF readers and I don't have to deal with Adobe anymore to read a portable document format.
Earlier quoted context omitted.
Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if jav…
You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should…
The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively. Would like to know if an installation is vulnerable if: 1) If Applications, PDF is set to "Always ask" 2) Ublock and/or privoxy are used 3) Javascript is disabled 4) pdfjs.previousHandler.alwaysAskBeforeHandling == false 5) pdfjs.disabled == true Also which advertising network and which Russ…
Hi, I reported this 0-day. It used a PDF.JS same origin policy violation to access local files. You should be safe because you have javascript disabled and pdfjs.disabled set to true. There's no way for the script to run. It was on a international news website operating from Russia. The exploit was not on an ad network. The exploit was simply injected on every news article page through an iframe. Therefore I assume t…