51–60 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.
A quick Google search found only four:
https://www.mozilla.org/en-US/security/advisories/mfsa2013-9... (another local file disclosure)
https://www.mozilla.org/en-US/security/advisories/mfsa2015-3... (needs to be "combined with a separate vulnerability" to be exploitable)
https://www.mozilla.org/en-US/security/advisories/mfsa2015-6... (needs to be "combined with a separate vulnerability" to be exploitable)
https://www.mozilla.org/en-US/security/advisories/mfsa2015-7... (this one)
It still is looking better than the plugin it replaced.
Why is anyone still using this browser anyway? Firefox is the new IE6.
Because it is the only browser that is not tied hand-and-foot to some major global commercial player, and because each and every browser ever launched had security issues. Even lynx is not immune: http://www.cvedetails.com/vulnerability-list/vendor_id-5836/...
I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…
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.
cf https://twitter.com/swiftonsecurity/status/62840155490772582...
I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…
Every major browser has a built-in PDF viewer (except maybe Safari? I don't own a mac). Mozilla's is the only one that's written in JS. The rest are proprietary native blobs. There have been security vulnerabilities (significant ones) found in the native PDF viewer blobs before, so given the choice between a same-origin policy breakage in pdf.js and an exploit in a native PDF viewer that can own my entire machine, I'…
I think the main reason Chrome bothered making one was because Adobe's reader kept having security vulnerabilities. I trust Chrome's one more than Adobe's. (I just looked up cvedetails.com for Adobe » Acrobat Reader. Security Vulnerabilities Total number of vulnerabilities : 434)
How many PDF.js security vulnerabilities have been found so far? A quick Google search found only four: https://www.mozilla.org/en-US/security/advisories/mfsa2013-9... (another local file disclosure) https://www.mozilla.org/en-US/security/advisories/mfsa2015-3... (needs to be "combined with a separate vulnerability" to be exploitable) https://www.mozilla.org/en-US/security/advisories/mfsa2015-6... (needs to be "combi…
Not for long if this keeps up…
Earlier quoted context omitted.
Docker containers can sandbox GUI apps[0], but I don't know if it's secure enough. Maybe not. [0]: https://news.ycombinator.com/item?id=8426764
I'm not sure if docker is the right solution here, a VM would seem to be much better at this kind of isolation. https://zeltser.com/security-risks-and-benefits-of-docker-ap...
even though I don't use pdf.js, have ublock and a strong key password, I'm not risking it.
I have access to so many servers, I'd rather spend 30 mins changing keys than take the chance