Development

Flash blocking, exploits, and replacements

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.

Comments (35 posted)

Quote of the week

Comments (none posted)

Coreboot 4.1 available

After more than five years of development, version 4.1 of coreboot is now available. The new release adds support for many more architectures (ARM, ARM64, MIPS, RISC-V) and numerous architectural changes, "like access to non-memory mapped SPI flash, or better insight about the internals of coreboot at runtime through the cbmem console, timestamp collection, or code coverage support." Maintainer Patrick Georgi promises that subsequent releases will appear on a more frequent basis.

Full Story (comments: none)

An end to XULRunner builds from Mozilla

At his blog, Ben Hearsum notes that Mozilla will stop performing automated builds of its XULRunner application runtime package, starting with the Firefox 41 development cycle in September. Automated builds have persisted in recent year only "because its build process also happens to build the Gecko SDK, which we do support and maintain. This will change soon, and we'll start building the Gecko SDK from Firefox instead". Developers using XULRunner will still be able to build the package themselves, although the preferred solution is to migrate away from XULRunner.

Comments (none posted)

Development newsletters from the past week

• What's cooking in git.git (July 10)
• What's cooking in git.git (July 15)
• Git Rev News (July 8)
• LLVM Weekly (July 13)
• OCaml Weekly News (July 14)
• OpenStack Community Weekly Newsletter (July 10)
• Perl Weekly (July 13)
• PostgreSQL Weekly News (July 12)
• Python Weekly (July 9)
• Ruby Weekly (July 9)
• This Week in Rust (July 13)
• Tor Weekly News (July 10)
• Tor Weekly News (July 15)
• Wikimedia Tech News (July 13)

Comments (1 posted)

An interview with Larry Wall (LinuxVoice)

Comments (199 posted)