Flash blocking, exploits, and replacements

By Nathan Willis
July 15, 2015

On July 13, Mozilla added the Adobe Flash Player plugin to its realtime blocklist for Firefox, citing unresolved security vulnerabilities that would enable remote attackers to compromise the user's system. Although Mozilla has blocked vulnerable versions of Flash on several occasions in the past, this most recent incident happened to coincide with a public call from a major web service provider to deprecate Flash entirely. That coincidence led to a lot of general-news (and some tech-news) outlets reporting that Mozilla had decided to block Flash on a long-term basis. Such was not the case, but the incident has once again raised awareness and public debate over what the right approach is to solving the "Flash problem."

The most recent block (which is detailed on Mozilla's blocklist site) was prompted by the discovery of three zero-day vulnerabilities in Flash that are known to be exploited in the wild by several rootkits. The vulnerabilities (CVE-2015-5119, CVE-2015-5122, and CVE-2015-5123) were discovered in the Hacking Team leak. Hacking Team is an Italian spyware-for-hire firm that has been accused of doing contract work for, among other clients, several national governments.

In early July, Hacking team itself was compromised, and 400GB of the company's internal data was leaked out over Bittorrent. The three vulnerabilities in Flash were revealed to be key entry points through which Hacking Team gained access to its victim's machines. Adobe issued a patch fixing CVE-2015-5119 on July 8, around two days after the leak was disclosed. By July 10, Mozilla decided that the other two vulnerabilities warranted implementing a block on the Flash plugin, and a bug report was opened.

The Firefox blocklist mechanism works by disabling the vulnerable plugin in running browsers, typically by putting the plugin into "click to activate" mode, which guards against sites automatically leveraging the exploit. Mozilla's standard procedure has been to initiate a block only when there was an update available, so that users would be able to upgrade to the latest, hopefully secure version of the plugin in question. A look at the realtime blocklist history shows that Mozilla has used the blocklist feature on Flash six times in 2015 already.

As luck would have it, though, the July 13 block happened to coincide with some other public commentary about Flash's security problems on social media. First, Mozilla's Mark Schmidt announced the block on Twitter, calling it "BIG NEWS!!" and including an "Occupy Flash" image beneath the text. Judging by the replies to Schmidt's news, more than a few people mistook that announcement to be a long-term policy decision; Schmidt later clarified that the block was temporary "for now", pending updates from Adobe.

But Schmidt's tweet came just one day after Facebook's security chief Alex Stamos said: "It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers to set killbits on the same day." Subsequently, word spread that Mozilla's move was a response to Stamos's call to action. News outlets ranging from gadget blog Gizmodo to the BBC linked the events—although most eventually sorted out the nuances and updated their coverage.

Still, the question remains open whether or not protecting Firefox users from Flash exploits is worth the effort. The Flash plugin is subject to dozens of CVEs every year and, after each incident, Mozilla must wait for Adobe to release another update. Mozilla's realtime blocklist feature has been in place since 2008 and, while Flash competes with the Java plugin for the title of most-frequently blocked, the total number of blocklist incidents does not seem to be decreasing.

At the same time, Flash replacements still have not made the binary Adobe plugin obsolete. While a number of top-tier video sites support HTML5 media playback—which was once cited as the main reason Flash persisted—many others do not. Quite a few sites with no media-playback functionality at all still use Flash—GitHub, for example, uses Flash to provide its one-click "copy to clipboard" button (a feature it added in 2013).

In 2012, Mozilla announced Shumway, an open-source Flash runtime implemented in JavaScript that would eventually be able to replace Adobe's binary Flash plugin. We looked at Shumway shortly after the announcement, and again in 2013 when Shumway was merged into Firefox (as a feature that users could enable in the about:config screen).

But Shumway's progress has been slow. Its most recent status update marks it as a possible feature for Firefox 42 (scheduled for November 2015). But that status report also notes that the target use case is replacing Flash-based ads, and suggests that the feature might be pulled from Firefox in favor of providing a Flash-compatible JavaScript library to ad-delivery networks.

While providing an alternative ad-building tool to online advertisers might reduce the amount of Flash content delivered as a whole, that alone would hardly obviate the need for end users to have the binary Flash plugin installed on their computers. Despite Stamos's understandable dissatisfaction with Flash, Facebook still uses it for embedded videos—and there are still countless sites like GitHub that use Flash as a workaround for some limitation in the traditional HTML document object model (DOM). There is a working draft from the W3C for a Clipboard API that could replace GitHub's copy-to-clipboard Flash snippet, but W3C specifications are not fast-moving entities.

For now, it is welcome news to hear that Stamos and others understand the risky nature of supporting Flash—and to hear them speak out in favor of doing away with it. But those calls to action are nothing new. It has been five years since Steve Jobs famously lambasted Flash in public and two years since Mozilla merged Shumway into Firefox, but Flash does not appear to be that much closer to disappearing. While it would be nice to think that the Hacking Team exploits would catalyze the industry to do away with Flash, the format has proven more than a little resilient over the years.

Index entries for this article
Security	Flash

to post comments

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 1:07 UTC (Thu) by dlang (guest, #313) [Link] (7 responses)

If flash was only needed for ads, nobody would worry about disabling it (the advertising companies would adapt very quickly)

The problem is that it's used for far more than that, and the replacements are poor. In my case I need it to run the vmware console at work, and currently I can't even do that on firefox because it requires a newer version of flash than Adobe makes available for Linux (so I'm stuck firing up a windows vm for the console)

Unfortunately, calls to get rid of it on the Internet are not going to get rid of it as a console for internal tools. Something is needed or people will just start running other OSs rather than continuing to fight.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 7:33 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Regarding "the replacecments are poor": KVM has been providing a HTML-based console for years now. The hosting providers I use have HTML-based consoles.

Naturally this doesn't mean that such potential replacements will magically allow you to work with the flash-based console at work.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 18:07 UTC (Thu) by derobert (subscriber, #89569) [Link] (5 responses)

FYI: Flash 18.x is available as part of Chrome on Linux. It also works on Chromium (e.g., with Debian's pepperflashplugin-nonfree package). That should at least save you from the Windows VM.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 19:20 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

hmm, doesn't work for me

dpkg -l |grep pepperflashplugin-nonfree

ii pepperflashplugin-nonfree 1.7ubuntu1 amd64 Pepper Flash Player - browser plugin

but firing up chromeium doesn't seem to be using it.

ubuntu 15.04

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:47 UTC (Thu) by derobert (subscriber, #89569) [Link]

Odd; did it download the plugin? You can try sudo update-pepperflashplugin-nonfree --install to force it to. I use Debian personally, so I can't vouch the Ubuntu package actually works.

It ultimately works by passing the .so to Chromium on the command line (see /etc/chromium.d/pepperflashplugin-nonfree, at least that's where it is on Debian), so if the package is somewhat broken on Ubuntu, easy enough to work around.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:55 UTC (Thu) by Anssi (subscriber, #52242) [Link] (1 responses)

The Chromium wrapper shell script needs to detect the pepper flash player and give it is a a parameter to chromium, is that happening?

If Ubuntu carries pepperflashplugin-nonfree, I'd assume the chromium startup script would also be properly adapted.

You can also try it manually:

$ CHROME_FLASH="/opt/google/chrome/PepperFlash/libpepflashplayer.so"
$ CHROME_FLASH_MANIFEST="/opt/google/chrome/PepperFlash/manifest.json"
$ CHROME_FLASH_VERSION="$(awk -F'"' '{ if ($2 == "version") { print $4; exit; } }' "$CHROME_FLASH_MANIFEST")"
$ chromium-browser --ppapi-flash-path=$CHROME_FLASH --ppapi-flash-version=$CHROME_FLASH_VERSION

Flash blocking, exploits, and replacements

Posted Jul 17, 2015 1:02 UTC (Fri) by dlang (guest, #313) [Link]

Thanks for this. It turns out that on ubuntu everything is in different places (/usr/lib/pepperflashplugin-nonfree instead of opt/google/chrome/PepperFlash) but what was causing the grief was that Adobe flash was installed and /etc/chromium-browser/customizations/10-flash was overriding the settings that pepper flash had installed.

Flash blocking, exploits, and replacements

Posted Jul 23, 2015 9:06 UTC (Thu) by eternaleye (guest, #67051) [Link]

I just discovered this recently, and you may find it useful; it's a Firefox-compatible NPAPI plugin that is capable of loading the Chrome Pepper Flash plugin:

https://github.com/i-rinat/freshplayerplugin

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 3:37 UTC (Thu) by roc (subscriber, #30627) [Link] (2 responses)

Firefox Aurora supports the W3C copy and paste APIs. https://bugzilla.mozilla.org/show_bug.cgi?id=1012662
This will reach release in Firefox 41 in late September. I think Chrome releases already support it. So that issue is going away.

Eliminating Flash is a long, hard and painful process, and it will never really end since there will always be Flash objects in legacy Web pages. But a lot of the hard work has been in making sure everything Flash does can be done without Flash (even very awful things like DRM), and that work is nearly done.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 18:19 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

Thank you for finally fixing that.

There's a few badly-designed sites that forcibly select all of a textbox when it's focused using JS, and expect the end user to Ctrl+C that, which makes it impossible to middle click paste. That's an extremely annoying usability issue when GitHub does it for clone URLs that are supposed to be pasted into a terminal window. YouTube is guilty too for the "share at current time" URLs. About time people stopped doing it.

Flash blocking, exploits, and replacements

Posted Jul 18, 2015 20:58 UTC (Sat) by ploxiln (subscriber, #58395) [Link]

If I can successfully lobby for auto-select for manual copy *instead of* a copy button, I do so. Originally because that's such a minor convenience to exchange being flash-free for. Even now I'm a bit suspicious of adding the feature natively to browsers - it's probably not a good idea in general. You'll notice that there's a scheme where it's only allowed for execution contexts that are caused directly by a mouse click (there's a similar scheme for requesting desktop notifications). But browsers are already extremely complicated runtimes, and this measure doesn't strongly control the UI... so you just know there's going to be a good handful of real exploits that utilize this feature over the next few years.

You can probably do a version that selects the full thing initially, but doesn't interfere with your manual selections after that. Even if not, I'd give up middle-click-paste, rather than allow flash or javascript access to clipboard. If it were me calling the shots anyway.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 18:23 UTC (Thu) by PaXTeam (guest, #24616) [Link] (19 responses)

i can't help but wonder... what would Mozilla have done if the Hacking Team stash had contained Firefox exploits? close down shop for good? didn't think so either. next, what's the point of temporarily blocking Flash Player versions? do these versions stop having exploitable bugs while not blocked? didn't think so either. there's also a certain irony in that Firefox is the one and only piece of software i've seen in the past 15 years that intentionally triggers non-executable violations on itself, making it impossible to distinguish actual exploit attempts. but then it's so much easier to hate on someone else's software with great publicity and fanfare instead of actually improving security, isn't it.

it's also a pity that LWN chose to join the propaganda du jour instead of recognizing the wider (and actual) issue we see here: complex software will always have bugs, regardless if it's called Flash Player or Firefox or Linux or whatever. instead of not using said software, we should figure out how we can still use them in a safe way. that'd of course result in less circus and hype to talk about so it's no wonder that certain parties are so vested in the status quo.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 19:58 UTC (Thu) by dlang (guest, #313) [Link] (14 responses)

> what would Mozilla have done if the Hacking Team stash had contained Firefox exploits? close down shop for good?

no, they would release patches to fix it.

But they can't do that with flash, all they can do is make it not run by default until Adobe decides to fix it. Which is what they did.

> instead of not using said software, we should figure out how we can still use them in a safe way.

Actually, the right thing is to get the software fixed. But we can't do that with proprietary software that the vendor is refusing to maintain.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:17 UTC (Thu) by PaXTeam (guest, #24616) [Link] (13 responses)

> no, they would release patches to fix it.

which is exactly what Adobe did. on the other hand Adobe doesn't blacklist Firefox versions when they turn out to have exploitable bugs.

> But they can't do that with flash,

why would they have/want to do that? it's not their code regardless of source availability. after all you're not fixing exploitable linux security bugs either even though you have the source code but the lack the expertise/time/test env/etc.

(not to mention that lack of source code doesn't prevent fixing bugs per se, it just makes it easier.)

> all they can do is make it not run by default until Adobe decides to fix it. Which is what they did.

which makes no sense since all versions to date have exploitable bugs. ditto for Firefox. now what? ;)

> Actually, the right thing is to get the software fixed.

the right thing to do is to do what is actually possible to do. fixing all bugs is not.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:29 UTC (Thu) by flussence (guest, #85566) [Link] (10 responses)

> which makes no sense since all versions to date have exploitable bugs. ditto for Firefox. now what? ;)

Since you're asserting that you know the current version of firefox has exploitable bugs, links to the filed bug reports would be nice. Assuming you don't want to further your reputation as a black hat, and asshat.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 21:42 UTC (Thu) by bronson (guest, #4806) [Link]

Black hat, white hat, ass hat... These lines are so blurry!

Flash blocking, exploits, and replacements

Posted Jul 20, 2015 15:08 UTC (Mon) by epa (subscriber, #39769) [Link] (8 responses)

I don't think it's an unreasonable assertion that the current Firefox version has exploitable bugs - it's just that they are not yet publicly known. Would you really want to wager money that there are no exploitable bugs in the current Firefox download? Would you even wager at ten to one that *no* such bug will be found within, say, a two year window?

Flash blocking, exploits, and replacements

Posted Jul 20, 2015 18:28 UTC (Mon) by dlang (guest, #313) [Link] (7 responses)

> I don't think it's an unreasonable assertion that the current Firefox version has exploitable bugs - it's just that they are not yet publicly known.

It's that last part "publicly known" that makes the difference.

Flash blocking, exploits, and replacements

Posted Jul 20, 2015 20:21 UTC (Mon) by PaXTeam (guest, #24616) [Link] (6 responses)

and what difference would that be (not a rethorical a queston)?

also how do you define 'public'? if a book can only be bought for money (seems to have been a trend for a few hundred years at least) then is that public or not? or does it have to be 'pirated' for it to be labeled as public?

Flash blocking, exploits, and replacements

Posted Jul 20, 2015 21:05 UTC (Mon) by dlang (guest, #313) [Link] (5 responses)

Ok, let's be more explicit.

Are there exploits circulating widely for any of the bugs?

If nobody knows about a bug, why does that bug hurt anyone?

Once the bug is known, then the question is if the bug can be exploited.

If the bug can be exploited by only a few people in the world, it's not nearly as big a deal as if the exploit has been packaged up so that script-kiddies can exploit it.

The Flash bug hit the script-kiddie stage (or if it didn't, it was extremely reasonable to assume that it would do so in a very short timeframe)

Now, you say that Firefox has lots of bugs in it. I don't disagree with you, the question is if there are specific bugs that are known to be exploitable where those exploits are available or likely to be available faster than the patches

Flash blocking, exploits, and replacements

Posted Jul 24, 2015 18:18 UTC (Fri) by PaXTeam (guest, #24616) [Link] (4 responses)

your logic(?) breaks down here:

> If the bug can be exploited by only a few people in the world, it's not nearly as big a deal as if the exploit has been packaged up so that script-kiddies can exploit it.

access to an exploit is only one of the factors that people take into account when assessing risk. not only that, you're also mixing up access to exploit with the ability and opportunity to use said exploits. the world's a whole lot more complex than what you assume here.

Flash blocking, exploits, and replacements

Posted Jul 24, 2015 21:49 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

I was talking only about the number of people who could use the exploit

Flash blocking, exploits, and replacements

Posted Jul 24, 2015 22:04 UTC (Fri) by PaXTeam (guest, #24616) [Link] (2 responses)

epa was talking about exploitable bugs, not exploits. why you brought up exploits is something you have yet to explain. next, knowledge of exploits != possession of exploits != ability to use exploits != opportunity to use exploits. you haven't addressed any part of this.

Flash blocking, exploits, and replacements

Posted Jul 24, 2015 22:13 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> why you brought up exploits is something you have yet to explain

Because the topic of this discussion is why Mozilla changed flash from always activate to click to activate ('blocking' flash) and why Adobe shouldn't block firefox because it has bugs

Mozilla did so because of the exploits circulating for Flash

If there are similar exploits circulating for Firefox, they are not well known.

Ranting about the unknown exploitable bugs in firefox is meaningless. What matters is what exploits available to who. At a project level It doesn't matter if there are millions of exploits if the number of people who know them are tiny, what matters is only exploits that are known and usable by many people.

Forgetting this is a very common problem security people have.

Flash blocking, exploits, and replacements

Posted Jul 24, 2015 22:25 UTC (Fri) by PaXTeam (guest, #24616) [Link]

no, the topic of this particular thread is about the existence of exploitable bugs in Firefox (and for all i care, we can extend it to other software too). you jumped in with an assertion and failed to prove it. now you came back with ad hominem and also repeated your claim as if that would somehow make it true. the problem with non-security people is that the world doesn't at all work the way they imagine it. for your particular erroneous statement, if it was true then there would be no market for 0-days (both bugs and exploits), never mind the current attempts at worldwide regulation.

Flash blocking, exploits, and replacements

Posted Jul 17, 2015 0:03 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> which is exactly what Adobe did. on the other hand Adobe doesn't blacklist Firefox versions when they turn out to have exploitable bugs.

isn't that exactly what their decision to not support firefox with any newer versions boils down to?

And how was Mozilla to know for sure that Adobe was going to break their 'no support' policy and update this ancient version of flash?

Flash blocking, exploits, and replacements

Posted Jul 17, 2015 8:28 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> isn't that exactly what their decision to not support firefox with any newer versions boils down to?

Adobe kept the linux flash player updated too (from the gentoo ebuild changelog that i have at hand):

*adobe-flash-11.2.202.481 (08 Jul 2015)
*adobe-flash-11.2.202.468 (24 Jun 2015)
*adobe-flash-11.2.202.466 (10 Jun 2015)
*adobe-flash-11.2.202.460 (13 May 2015)
*adobe-flash-11.2.202.457 (16 Apr 2015)
*adobe-flash-11.2.202.451 (13 Mar 2015)
*adobe-flash-11.2.202.442 (06 Feb 2015)
*adobe-flash-11.2.202.440 (27 Jan 2015)
*adobe-flash-11.2.202.438 (22 Jan 2015)
*adobe-flash-11.2.202.429 (14 Jan 2015)

and that's just this year. if you meant the major version then it's no different than any other vendor's policy, it's ultimately an economic decision, be that RHEL or Windows or Flash.

> And how was Mozilla to know for sure that Adobe was going to break their 'no support' policy and update this ancient version of flash?

it's a strawman, clearly there never was such a policy, except perhaps in your imagination ;). and even if there had been one, there's a thing called 'vendor communation channels' that all of these big players long ago established with each other.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:56 UTC (Thu) by job (guest, #670) [Link]

Propaganda or not, it's also true that some software is worse than others. The world would be a better place without Flash, and that has held true since the dawn of its existence.

Flash blocking, exploits, and replacements

Posted Jul 17, 2015 1:11 UTC (Fri) by roc (subscriber, #30627) [Link] (2 responses)

All software has bugs, but not all software has remote exploits against the latest version circulating in public. Given we can mitigate the impact of Flash exploits by making Flash click-to-play, it seems responsible to impose that while Flash is in the latter category.

If there was a remote exploit against Firefox circulating in public, and we could push out some kind of mitigation faster than pushing out a full fix, I hope we would.

Flash blocking, exploits, and replacements

Posted Jul 17, 2015 8:50 UTC (Fri) by PaXTeam (guest, #24616) [Link] (1 responses)

> it seems responsible to impose that while Flash is in the latter category.

i wouldn't call giving a false sense of security to all your users 'responsible', quite the opposite in fact. unless you can explain how a non-click-to-play version of Flash is suddenly free of exploitable bugs (rhetorical question of course as the HT and other 0-day exploits prove the opposite). what you're doing is window-dressing and giving an appearance of 'doing something' but that something is utterly useless and it most definitely does not improve anyone's security.

> If there was a remote exploit against Firefox circulating in public[...]

i'm sure there is one but it has yet to reach someone at mozilla.org. what's that matter? if you don't know about a specific threat then it doesn't exist and you have nothing to do? that's exactly the kind of thinking that's kept everyone in the dark age of 'security' and 'do something's.

Flash blocking, exploits, and replacements

Posted Jul 18, 2015 20:45 UTC (Sat) by KaiRo (subscriber, #1987) [Link]

Please read carefully before you write. roc was talking about publicly circulating exploits, not about theoretically exloitable bugs.

Flash blocking, exploits, and replacements

Posted Jul 16, 2015 20:44 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> The Firefox blocklist mechanism works by disabling the vulnerable plugin in running browsers, typically by putting the plugin into "click to activate" mode, which guards against sites automatically leveraging the exploit.

Too bad everyone (including Firefox) calls "blocking" what is actually just click to activate. I've been using click to activate for Flash with every browser since forever and it's just a great, useful feature on its own. It just happens to be good for security.

Flash blocking, exploits, and replacements

Posted Jul 18, 2015 21:11 UTC (Sat) by ploxiln (subscriber, #58395) [Link] (2 responses)

I've also long used the Flashblock plugin for Firefox, which offers click-to-play. Very briefly, click-to-play was a hidden option built-into Firefox, but then it went away in favor of full page/site enable/disable, presumably because they didn't want non-advanced users confused about why a site which depends on a hidden flash frame doesn't work. Chromium has offered click-to-play for a long time, though now it's not as straightforward (option renamed, and it's right-click-select-run).

Anyway, yup, click-to-play / click-to-activate will save you from almost all the grief of having the flash plugin installed. Ad networks in particular are a huge risk of unexpected third-party stuff running in the page (spinning your cpu and often a vector for attack code), which you avoid if you just click the main video/game frame.

Flash blocking, exploits, and replacements

Posted Jul 19, 2015 21:22 UTC (Sun) by branden (guest, #7029) [Link] (1 responses)

Ad networks in particular are a huge risk of unexpected third-party stuff running in the page (spinning your cpu and often a vector for attack code), which you avoid if you just click the main video/game frame.

Ah, I remember when Bruce Perens was telling us we had a ethical obligation to view advertising, and hectored us ad-blockers that the value delivered by ad-supported sites the web would be rightfully withdrawn if enough of us recalcitrant power users violated the social contract by refusing to lend our eyeballs to whatever ads came our way.

Does it surprise anyone that advertisers won the race to ethical corruption?

Flash blocking, exploits, and replacements

Posted Jul 20, 2015 0:20 UTC (Mon) by marcH (subscriber, #57642) [Link]

You're digressing a bit; Flash and ads are overlapping yet clearly different topics.

I'm sure ads can learn HTML5 quickly enough - a win for everyone.