Last Comment Bug 436348 - Blocklist vulnerable versions of flash
: Blocklist vulnerable versions of flash
Status: RESOLVED DUPLICATE of bug 526019
[sg:want P1]
:
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
-- normal (vote)
: ---
Assigned To: Michael Morgan [:morgamic]
:
: Jorge Villalobos [:jorgev]
Mentors:
http://blogs.zdnet.com/security/?p=1189
Depends on:
Blocks: 496630
  Show dependency treegraph
 
Reported: 2008-05-29 12:47 PDT by Dave Townsend [:mossop]
Modified: 2016-03-07 15:30 PST (History)
25 users (show)
samuel.sidler+old: blocking1.9.0.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Dave Townsend [:mossop] 2008-05-29 12:47:30 PDT
The latest flash exploit seems pretty serious and prevalent, we should consider blocklisting the affected versions, assuming there is an unaffected version that is.
Comment 1 User image Robin Mulder 2008-05-31 11:42:33 PDT
See http://blogs.adobe.com/psirt/2008/05/potential_flash_player_issue_u_1.html and http://blogs.adobe.com/psirt/2008/05/more_information_on_recent_fla.html for more information from Adobe. According to that article the bug was resolved in Flash Player 9.0.124.0 and does not exist in Flash Player 10 beta.

The bug exists on all platforms but only Windows users seem to be targeted by the exploits currently out there.
Comment 2 User image Michael Morgan [:morgamic] 2008-05-31 14:58:29 PDT
I think blocklisting would be a good idea.  It is effective and forces users to upgrade.
Comment 3 User image Michael Morgan [:morgamic] 2008-06-12 13:29:44 PDT
When do we need this out by?
Comment 4 User image Dave Garrett 2008-07-03 21:46:44 PDT
Have any decisions been made with respect to this?  Blocking old vulnerable versions of Flash seems like a very good idea.

In addition, once Flash 10 gets out of beta I think blocking all older versions would be very useful.  Not only would it help to avoid fixed crashes and exploits, but it also would let the crash reporter finally work correctly again.  (bug 422308)  Flash 10's system requirements drop a few supported systems, but Firefox 3 drops similar ones so I don't think there'd be a problem there.  (drops MacOSX 10.1-10.3, Windows 98, and some older Linux distros)
Comment 5 User image timeless 2008-07-03 23:52:39 PDT
my understanding is we have per release blocklists. I'm using FF2 on OS X 10.3.9, and I would not appreciate losing Flash just because Flash 10 is released.

However, I think it's reasonable to blocklist Flash 9 < 9.0.124.0 today (forever)
and when Flash 9 loses support, then the FF3 blocklist can blocklist Flash 9 entirely.
Comment 6 User image Michael Morgan [:morgamic] 2008-07-03 23:54:40 PDT
Not yet, Dave -- will bring it up next Monday so we can get some movement on it.
Comment 7 User image Dave Garrett 2008-07-04 11:28:35 PDT
I was suggesting requiring Flash 10 only on FF3.  Setting a min of 9.0 r124 on FF2 would be needed there, for the exact reason you mentioned.  Now that I'm looking at the syntax of the blocklist file, I'm realizing that this sort of thing is only supported for extensions and not plugins.  Is there any way this could be worked around?  Without the fix for 422308 in there we're missing an unknown number of crash reports.
Comment 8 User image Jesse Ruderman 2008-07-14 15:28:29 PDT
Given the widespread exploits against old versions of Flash, I think we should do this ASAP.
Comment 9 User image Daniel Veditz [:dveditz] 2008-07-14 16:03:04 PDT
This is what we'd want:

    <pluginItem>
      <!-- All match tags must match a plugin to blocklist a plugin -->
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*([0-8]|9\.0\s*r(\d\d?|1[01]\d)$)"/>
    </pluginItem>  

If people prefer readable we can split it up, and explicitly list only the known released versions of Flash. On the Adobe site I was only able to find the following 9.0 versions: 16, 20, 28, 45, 47, 48, 115, 124.  I thought I remembered one between 47 and 115 but I can't find it, maybe I'm thinking of some other plugin.

    <pluginItem>
      <!-- All match tags must match a plugin to blocklist a plugin -->
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*[0-8]"/>
    </pluginItem>  
    <pluginItem>
      <!-- All match tags must match a plugin to blocklist a plugin -->
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*9\.0\s*r(16|2[08]|4[578]|115)$"/>
    </pluginItem>  

Is that any better? I'd rather go for the more inclusive version range rather than take the risk of missing some. (Technically the first regexp only catches up to r119, but there wasn't anything between r115 and r124 so it's simpler that way.)

"Shockwave Flash\s*(?=9.0 r124)" is temptingly simple, but then everyone's broken the day Adobe releases an update.

Reassigning to Basil to do whatever official stuff needs to happen, then it can go back to morgamic's team to implement. I marked it blocking for 3.0.2 just to put an upper bound on it happening but it doesn't have to be tied to a release. In fact we could do it this week with the 3.0.1 release, or next week with no particular release at all.
Comment 10 User image Daniel Veditz [:dveditz] 2008-07-14 17:27:08 PDT
> "Shockwave Flash\s*(?=9.0 r124)" is temptingly simple,

I meant "(?!9.0 r124)" of course, but I still don't recommend that form.

All the forms I gave will block Shockwave Flash 10 when it comes out. We can disambiguate either by blocking fewer old versions or matching on '.'

  "Shockwave Flash\s*([2-8]\.|9\.0\s*r(\d\d?|1[01]\d)$)"
Comment 11 User image Basil Hashem [:baz] 2008-07-16 18:28:13 PDT
Reached out to Adobe contacts, awaiting response.
Comment 12 User image Daniel Veditz [:dveditz] 2008-08-13 02:00:06 PDT
Meanwhile last week popular site CNet was serving up malware using the same CVE-2007-0071 Flash flaw, fixed in 9.0r124 but not earlier version. http://securitylabs.websense.com/content/Alerts/3151.aspx
Comment 13 User image Samuel Sidler (old account; do not CC) 2008-08-14 16:57:55 PDT
I don't think we want to block 1.9.0.2 on this since it's server side. But what's the status here?
Comment 14 User image Aiko 2008-11-10 14:11:09 PST
I would strongly suggest that you blocklist Flash 8 because I believe it's the cause for one of the Firefox 3.0.3 topcrashers, the one with @0x300d4eea at the top of the stack. If you take a look at these crashes, one DLL that usually everybody has is suspiciously absent in the module list of all of them: NPSWF32.DLL

0x30000000 was the preferred load address of Flash 8, maybe Flash 8 managed to hide itself or it got unloaded somehow.
Comment 15 User image Dave Garrett 2008-11-10 15:44:04 PST
There's plenty of fixed crashes in Flash 9, too. If it weren't for the fact that Flash 10 drops support for some OSes that Firefox 2 still supports, I'd recommend we ban up to Flash 9 entirely. Flash 9 needs to go if just to fix bug 422308, which prevents us from really knowing all the top crashes.

This has been put off for months now. Can we please get an actual decision on this and get these old versions blocked? Blocking all but the latest v9 Flash for everyone is needed. Firefox 3+ really should require Flash 10+, but that would require app version support to be added in.
Comment 16 User image Dave Garrett 2008-12-23 14:52:34 PST
Here's some updated regexp. The current v9 is r151 on Win/Mac and r152 on Linux. (http://www.adobe.com/go/kb406791) Note the trailing "\." in the first and last ones, as otherwise it'll block v10. Please correct me if I'm wrong here:

For FF2- we'll want:
    <pluginItem>
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*[0-8]\."/>
    </pluginItem>
    <pluginItem>
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*9\.0\s*r(\d?\d|1[0-4]\d)$"/>
    </pluginItem>

For FF3+ we'll want:
    <pluginItem>
      <match name="name" exp="Shockwave Flash"/>
      <match name="description" exp="Shockwave Flash\s*[0-9]\."/>
    </pluginItem>

This should block up to 9r149 in Firefox 2 and all versions before 10 in Firefox 3+. I don't know what's involved in using both sets, but we can't require v10 in FF2 because it doesn't support Win9x and old MacOSX versions while FF2 does. The current FF2 blocklist is different from FF3's (lacks plugins) so I would hope that different versions of this file could just be served up to the different app versions. What's possible here?

This issue hasn't been dealt with for half a year now. Is this doable in some form at some point in the not too distant future?
Comment 17 User image timeless 2009-01-12 18:09:25 PST
the qt blocklist bug mentioned that we don't have support for blocklisting plugins in ff2 ....
Comment 18 User image Dave Garrett 2009-01-12 18:26:34 PST
Ah, thanks for correcting me. I couldn't find a good answer on this. Disregard half of my comment then. ;)

Then this should be as simple as blocking "Shockwave Flash\s*[0-9]\.".
Comment 19 User image Michael Morgan [:morgamic] 2009-01-23 11:09:03 PST
This has the potential to affect a lot of users in a bad way.  Does someone have metrics on Flash use so we understand what % of ADU are affected by this before we proceed?  Chris?
Comment 20 User image chris hofmann 2009-01-23 17:48:44 PST
we are working on some better system to figure out where things are now, and to track progress of how to get all plugins updating to latest versions.  The more that we look at it the bigger the problem is.  From the data that we have now maybe about only 40% of firefox users are running latest releases of flash 10.
Comment 21 User image Dave Garrett 2009-07-24 23:02:04 PDT
With new and interesting reasons to blocklist (http://www.adobe.com/support/security/advisories/apsa09-03.html), what's the progress on this? Will we be able to at some point block all but the current version after the next fix? Do we even fully comprehend how bad the problem is yet?

This would affect a lot of people, but then again, the security holes, crashes, and other bugs already affect a lot of people in a far more negative way.
Comment 22 User image Michael Morgan [:morgamic] 2009-09-28 22:34:44 PDT
Mike and Mike - do we want to bury the hatchet???
Comment 23 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-09-29 14:34:19 PDT
I'll take a look at this, see what the hatchet-status is.

Aside: "consider X" is a terrible way to summarize a bug, since it is trivially closed ("thought about it") and reopened ("think about it some more") without useful progress!
Comment 24 User image chris hofmann 2009-09-29 15:19:42 PDT
we should get ken to post latest stats on the effectiveness of click thoughs and marketshare changes on getting users to update via the recent press campaign.

http://blog.mozilla.com/metrics/2009/09/16/helping-people-upgrade-flash/

A path of:

1) raise awarwarenss, and ask people to update though press outreach
2) get some visible product pages to encourage the updates

then

3) start blocking

might be a bit slower, but is less likely to cause user backlash that will send them to other browsers and equally (or worse) security risk.

measuring progress on 1 ande 2 is the key to understanding if that is an effective path, and with which the speed we need to jump to 3.
Comment 25 User image chris hofmann 2009-09-29 16:27:51 PDT
also to consider...

when this bug was filed a year and a half ago we knew about some particular nasty attacks running in the wild against a few versions of flash, and hence the idea that we might just block those few versions.  

In the year gone by we know of nasty attacks that running against just about all recent releases, so the blocking strategy might be more complex.  To put up a reasonable defense we would need to block these many versions.

blocking many versions and the resulting "overnight, youtube stops working for 50-60% of all firefox users" is the kind of effect that would drive users to other browsers.
Comment 26 User image Daniel Einspanjer [:dre] [:deinspanjer] 2009-09-29 18:49:09 PDT
Do these vulnerabilities affect the other browser vendors the same as us?  Do they have similar mechanisms to encourage plug-in upgrading or blocklisting? Maybe we could coordinate some sort of larger scale blocking event?
Comment 27 User image chris hofmann 2009-09-30 03:43:38 PDT
> Do these vulnerabilities affect the other browser vendors the same as us? 

yes, for chrome, safari, and other browsers that use NPAPI style plugins.

mostly yes, with small tweaks in behavior (that might make things worse) for IE activeX control style plugins.

A large scale blocking event with out first getting a lot of users upgraded and off the old versions of the plugins has effects like I mentioned earlier;  "overnight, youtube, and other popular sites that depend on flash, stop working for 50-60% of all web users"
Comment 28 User image u88484 2009-09-30 05:13:58 PDT
(In reply to comment #26)
> Do these vulnerabilities affect the other browser vendors the same as us?  Do
> they have similar mechanisms to encourage plug-in upgrading or blocklisting?
> Maybe we could coordinate some sort of larger scale blocking event?
How about just getting Adobe to do fix their own problems instead of trying to fix things for them (crashes and getting their users to upgrade).
Comment 29 User image Dave Garrett 2009-09-30 07:34:12 PDT
It's kind of annoying that the problem of vulnerable Flash versions is so bad that it makes it less desirable to block, even though that means it's a bigger problem. ;)

I think phasing this in might be a good idea to help with the expected user confusion. Here's a suggestion:

1) Block Flash 8 and older first. (comment 14) Would be nice to get numbers on how many people are running something this old, but I would hope it's a small enough number by now.
2) Soft block Flash 9 & old 10 versions. (warning w/ allowed usage) I'm not sure what the full status of this feature is, but I think 1.9.1 has some capability waiting on server work. (bug 462433)
3) After a month or two of a warning and a PR campaign, transition to a hard block for Flash 9 & old 10 versions.
Comment 30 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-09-30 10:31:25 PDT
(In reply to comment #28)
> How about just getting Adobe to do fix their own problems instead of trying to
> fix things for them (crashes and getting their users to upgrade).

How do you propose doing that?  Even if these crashes and exploits aren't our fault, they are very much our problem, because they put our users at risk and cause them significant grief.
Comment 31 User image Michael Morgan [:morgamic] 2009-09-30 10:34:28 PDT
We should be doing both, and we are.  Not much argument to be had there.
Comment 32 User image Samuel Sidler (old account; do not CC) 2009-10-13 18:31:57 PDT
I mostly agree with an approach like what comment 29 proposes.

However, before we start blocklisting versions of Flash, we should see how many users are on them and, probably, what OSes they're on. Are there times when Adobe shipped a new Flash version that didn't support an older OS that we still support? Flash 8 seems like an easy target, but let's ensure that we aren't forcing some users to not have Flash at all because a newer version of Flash doesn't exist for their OS.

Softblocking isn't really possible, iirc, but we should probably consider including it in Firefox 3.7 or 4.0. The filer of this bug would know. ;)
Comment 33 User image Samuel Sidler (old account; do not CC) 2009-10-13 18:35:58 PDT
(In reply to comment #32)
> Softblocking isn't really possible, iirc, but we should probably consider
> including it in Firefox 3.7 or 4.0. The filer of this bug would know. ;)

I'm such a liar. We can definitely softblock things as soon as bug 462433 is fixed, as comment 29 says.
Comment 34 User image Dave Garrett 2009-10-14 05:39:28 PDT
(In reply to comment #32)
> Flash 8 seems like an easy target, but let's ensure that we aren't
> forcing some users to not have Flash at all because a newer version of Flash
> doesn't exist for their OS.

Plugin blocking is only supported in Firefox 3 and later (comment 17).
http://www.mozilla.com/en-US/firefox/system-requirements-v3.html
http://www.adobe.com/products/flashplayer/systemreqs/

Firefox 3 supports a minimum of Windows 2000, Mac OS X 10.4, or Linux kernel 2.2.14. Flash 10 is well within that; it's supported on all systems Firefox 3 is, thus all systems we are capable of dealing with in this bug. (was noted in comment 4 & 16)
Comment 35 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-10-14 05:48:56 PDT
Is Flash 10 available for OS X on PPC?
Comment 36 User image Dave Garrett 2009-10-14 06:04:13 PDT
(In reply to comment #35)
> Is Flash 10 available for OS X on PPC?

Yes, Adobe's page says Mac OS X 10.4 or later for both PowerPC and Intel.

Only odd ball out on those pages I noted in comment 34 is Solaris, which is not supported with an official Mozilla build. Adobe supports up to Solaris 10. It looks like Firefox 3 can run on it just fine too.
Comment 37 User image Michael Morgan [:morgamic] 2009-11-02 13:14:13 PST
After recent events, I'm thinking we want to probably avoid this storm and approach it through proactive outreach like the firstrun warning and the plugin campaign.
Comment 38 User image Michael Morgan [:morgamic] 2010-01-20 17:03:42 PST
Discussion has since continued in bug 526019.  Please go there.

*** This bug has been marked as a duplicate of bug 526019 ***

Note You need to log in before you can comment on or make changes to this bug.