Firefox Under Fire: Anatomy of latest 0-day attack | Hacker News Reader

Firefox Under Fire: Anatomy of latest 0-day attack

welivesecurity.com

114 pointsadamnemecek42 comments

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.

1. https://wiki.mozilla.org/Fingerprinting

Apparently the bugs weren't in pdf.js, but in Firefox, and could be exploited through pdf.js and possibly other extensions.

https://news.ycombinator.com/item?id=10023517

Let's not give the project a bad name for someone else's bugs.

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.

Please have a look at the following comments: https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 and https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7

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.

Yeah, and that feature was only used in the Firefox deployment of pdf.js.

https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dd...

Not sure who's to blame, but like he said, there was no vulnerability in the web version.

That's correct. I don't think we should blame the PDF.js devs either.

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.

pdf.js was quite slow when it was first released. But have you tried it lately? It's a lot faster and less memory-hungry than it used to be. E.g. see https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-an... and https://blog.mozilla.org/nnethercote/2014/06/16/an-even-slim..., and there are plenty of other optimizations have occurred as well. It's PDF conformance has also improved greatly.

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.

> pdf.js was quite slow when it was first released. But have you tried it lately?

Not really. Even though I also do web development from time to time, I tend to favour native applications.

And as you acknowledge, it is still slower.

> 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 overwhelming majority of Firefox users are on Windows, so statistically this doesn't result in the conclusion you think it does.

Yes it does. Statistically, all Linux users running Firefox have been adversely affected when they needn't have been.

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.

1.) Displaying a message that the PDF may not be displayed correctly, which looked like this: https://support.cdn.mozilla.net/media/uploads/images/2013-03... except for the PDF of course, because it was loaded in a hidden iframe.

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.

It was completely invisible to the end-user from what I understand

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.

The list of affected sites is in the article, the only site that's not mentioned is: http://www.themoscowtimes.com/

It was served through ad networks, the only version in the wild I've heard of was targetting a russian network

It was disguised as an ad, not served through ad networks. In other cases it was disguised as a file from a CDN.

Yeah, I just wondered if any of these ad networks would be serving through any of the large-scale adult sites like pornhub, tube8, etc.

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 :)

[0] https://www.pcbsd.org/

[1] https://www.freebsd.org/

[2] https://www.freebsd.org/doc/handbook/jails.html

And if you develop jails, you get the kernel intrinsics that Docker leverages, which brings you back to Linux...

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.

Those intrinsics would be exactly cgroups, they isolate much more than just part of hierarchy in filesystem.

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:

    allow firefox_t user_home_t : file { read write };

This simply allows your web browser, running as firefox_t to read and write files in your home directory, labeled as user_home_t.

http://selinuxproject.org/page/FAQ#How_does_SELinux_work.3F

Why isn't SE linux more widely deployed? Is it something that can be turned on in existing installations?

Funny you should ask:

https://news.ycombinator.com/item?id=10025348

https://www.youtube.com/watch?v=bQqX3RWn0Yw

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.

On Linux, I use the unshare command to hide my /home, you can do the same thing with /etc:

  sudo unshare -m bash -c "mount --make-rslave / && mount -n -o bind /tmp/empty /home && sudo -u $(whoami) firefox -ProfileManager -no-remote"

it :

- forks the mountpoints table for the process to be executed (bash) - it requires capabilities (hence sudo),

- make / as as slave mount in this context (because of systemd which shares the / mountpoint (see: https://www.kernel.org/doc/Documentation/filesystems/shareds...),

- 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,

- I run firefox in user mode.

You can use selinux for that.

In Fedora there is an application called sandbox that help you with that

e.g. see http://www.bress.net/blog/archives/195-Firefox-in-a-sandbox-...

The sandbox -X command doesn't work: https://bugzilla.redhat.com/show_bug.cgi?id=1103622 - and hasn't worked for over a year.

The author is mia from the bug and seems to have given up: https://danwalsh.livejournal.com/72697.html

You could use firejail[1].

[1]: https://l3net.wordpress.com/2014/09/19/firejail-a-security-s...

A quite beautiful bug! The fact it searches your computer for filezilla/etc server credentials is just as beautiful!!

This is a lesson for those who continue to save their filezilla/etc passes in plaintext.. Stop being lazy and type your password each time.

Can anyone explain what the bug was?

This previous thread has links to more detail: https://news.ycombinator.com/item?id=10021376

But none that describe the cause of the bug, right?

Well, the person who reported the bug comment in depth details of what it does from his point of view on that link.

So yes?

ctrl+f to find user "fukusa" and you'll find that one of his/her comment goes into depth.

Thanks, also have a look at: https://news.ycombinator.com/item?id=10047010

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]

[1] https://github.com/mozilla/gecko-dev/commit/2e67509c8a3cefe8...

[2] https://github.com/mozilla/gecko-dev/commit/8b7f7bde8f21bd71...

Reply on news.ycombinator.com