

Firefox Under Fire: Anatomy of latest 0-day attack - adamnemecek
http://www.welivesecurity.com/2015/08/11/firefox-under-fire-anatomy-of-latest-0-day-attack/

======
pissedffuser
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](https://wiki.mozilla.org/Fingerprinting)

~~~
yAnonymous
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](https://news.ycombinator.com/item?id=10023517)

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

~~~
fukusa
Please have a look at the following comments:
[https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5](https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5)
and
[https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7](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.

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

[https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dd...](https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dda8c5597a4d3523c5f1423)

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

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

------
neuromute
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)?

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

~~~
neuromute
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.

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

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

------
wjnc
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.

~~~
tachion
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/](https://www.pcbsd.org/)

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

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

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

~~~
tachion
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.

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

------
hlfw0rd
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.

------
pjtr
Can anyone explain what the bug was?

~~~
mbrubeck
This previous thread has links to more detail:
[https://news.ycombinator.com/item?id=10021376](https://news.ycombinator.com/item?id=10021376)

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

~~~
digitalzombie
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.

~~~
fukusa
Thanks, also have a look at:
[https://news.ycombinator.com/item?id=10047010](https://news.ycombinator.com/item?id=10047010)

~~~
pjtr
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...](https://github.com/mozilla/gecko-
dev/commit/2e67509c8a3cefe8c0cdf74922f02c340543b17f)

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

