Even if PDF.js is in general more secure than certain external PDF readers, it now provides a common attack surface for potentially every platform FF runs on, and therefore, it could make FF less secure on certain platforms than it would be if it simply delegated to whatever PDF reader the platform or users prefer. Instead of having to find 0-days for Adobe Reader on Windows, Evince/Okular on Linux, and others, they only had to find a flaw in PDF.js itself.
The PDF.js project was started largely because Adobe Reader has a horrible security track record and Windows users don't keep it up to date. Well, Linux users don't generally use Reader, and they benefit from package management, so they were just needlessly put at risk to protect others.
I have changed FF to open all PDFs with Evince, and I couldn't be happier. It's faster and has a better UI. I've added it to the ever-growing checklist of things to do after installing FF, which includes installing multiple plug-ins to partially mitigate browser fingerprinting, something that Mozilla has known about at least since 2010 but has done virtually nothing to prevent[1] and something that I and many other users would prefer they work on instead of PDF.js or Pocket integration.
The original blog post from Mozilla explicitly stated versions of Firefox without pdf.js were unaffected and a Mozilla employee confirmed disabling pdf.js would be enough to protect against the exploit. Mozilla was also extremely cagey about the nature of the exploit, its severity, and who might have been affected by it.
If people were misled into thinking pdf.js was completely to blame, then that's Mozilla's fault.
As far as I understand PDF.js used the 'PlayPreview' feature (Playpreview is the overlay you get to see to confirm you want to activate a plugin) as a 'hack' to inject PDF.js HTML content (resource://pdf.js/web/viewer.html) into the page because the plugin architecture was not flexible enough. So, even though technically PlayPreview is not part of PDF.js, the combination of PDF.js and PlayPreview specifically made it possible to inject content into PlayPreview and bypass the CSP.
I cannot cope with PDF.js, always making sure an external viewer is used.
It doesn't matter how beefy a machine is, the world freezes when a PDF is being open. Then there is the slow pagination, zooming and lots of boxes instead of characters.
It's still not as fast as a native PDF reader, and probably never will be. When I'm dealing with really large PDFs (e.g. the Intel x86 docs, which are 1000+ pages) I still use a native PDF reader. But I find that pdf.js does just fine on documents of up to a few hundred pages. Which is, y'know, most of them.
And having PDFs open in the browser is so convenient -- I get a happy feeling every time I open a PDF and I don't get a dialog asking me to save this file and/or open it in an external application.
Linux users of Firefox are a tiny minority of Firefox users. The overall diversity, when considering the ecosystem as a whole, doesn't change much with the addition of pdf.js.
Compared to the large improvement in security that the JS sandbox provides (and yes, sandboxes do improve security despite sometimes having holes) compared to (say) unsandboxed Evince, the security benefit from diversity is minimal.
I don't care that much about fingerprinting. For example, the problems with navigator.plugins fingerprinting is small compared with the problems in the plugins themselves.
If you were hit with this attack, would you see a pdf attempt to load in the browser? Was it a hidden iframe? Were any popular tube sites affected (PH-network, etc)?
Now that this has been disclosed, one of the affected websites that has not been listed is: http://www.themoscowtimes.com/. I was a victim of the exploit myself, so if you have visited that website before August 8, you might have been as well. The attempt to load a PDF was visible in the browser in 2 ways.
2.) In my case the exploit tried to open one of my public keys (with the .pub file extension) but because the browser determined this was an executable file (because of the mime-type) that should not be displayed by the browser it triggered a file dialog asking me to open the file with some other program. This is what alarmed me and that way I discovered this 0-day. I must say however that other versions of the exploit have surfaced that do no longer target the public key file (maybe for this reason?) so the file theft may not be noticed.
So, is there a comprehensive list of affected sites anywhere? I've seen a short list of sites serving the malware, but I see no mention of whether this was distributed via any large-scale tube sites.
If it was attempting to search the whole filesystem for interesting files to upload, I think that might be somewhat noticeable - at least for those who don't have an SSD, or have a HDD activity light in plain view. If some process on my system suddenly decides to scan the filesystem, I'd definitely notice the HDD seeking.
How hard would it be to strengthen a Linux-system to make the browser operate with less rights in order to give an attacker less access to the /etc/* folders? Because that seems to be the main angle of attack. Get user permission via bug in browser, just download a lot of files / folders and see if anything useful pops up.
I dont know about Linux, but if you'd be comfortable leaving it-is-linux-only-that-exists land, then PC-BSD[0], which is a desktop focused distro of FreeBSD[1], allows you running your browser in a Jail[2], which is a container technology with years of battle experience in production :)
What are those exactly? Docker seems to me more like a userland glue for kernel based containers, and since it's starting to support FreeBSD Jails, I dont see why again it has to lead to Linux only, instead to FreeBSD OR Linux (or anything else supported by libcontainer for that matter). The main point is, Linux is not the only thing, and talking like that reinforces that incorrect point of view in other unaware people. Technology diversity is extremely important and cool thing.
Running applications also have labels. For example, your web browser may be running as firefox_t. Type enforcement simply allows you to specify what application label can access what resource label. In the most simple terms SELinux lets you allow an application to do something with a resource:
A (deserved, but outdated) reputation for breaking things and being hard to configure, nonexistent or inferior toolsets on non-RPM distros due to lack of support on same.
- bind an empty directory to /home (that I previously created), it will only be visible for this process and its children, since it's in an unshared mountpoints table,
Thanks, that's closer to what I was looking for. I'm still a bit unclear on what exactly the root cause of the bug is. A flawed plugin API (PlayPreview), flawed usage of that API, a bug in the implementation of that API, a combination of these or something else. From your link it looks like the plugin now does not use the API anymore, but the API still exists. But the API implementation seems to have required fixes as well. [1] [2]
The PDF.js project was started largely because Adobe Reader has a horrible security track record and Windows users don't keep it up to date. Well, Linux users don't generally use Reader, and they benefit from package management, so they were just needlessly put at risk to protect others.
I have changed FF to open all PDFs with Evince, and I couldn't be happier. It's faster and has a better UI. I've added it to the ever-growing checklist of things to do after installing FF, which includes installing multiple plug-ins to partially mitigate browser fingerprinting, something that Mozilla has known about at least since 2010 but has done virtually nothing to prevent[1] and something that I and many other users would prefer they work on instead of PDF.js or Pocket integration.
1. https://wiki.mozilla.org/Fingerprinting