Closed Bug 436348 Opened 17 years ago Closed 15 years ago

Blocklist vulnerable versions of flash

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 526019

People

(Reporter: mossop, Assigned: morgamic)

References

(
URL
)

Details

(Whiteboard: [sg:want P1])

The latest flash exploit seems pretty serious and prevalent, we should consider blocklisting the affected versions, assuming there is an unaffected version that is.
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.
I think blocklisting would be a good idea. It is effective and forces users to upgrade.
When do we need this out by?
Whiteboard: [sg:want P1]
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)
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.
Not yet, Dave -- will bring it up next Monday so we can get some movement on it.
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.
Given the widespread exploits against old versions of Flash, I think we should do this ASAP.
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.
Assignee: nobody → basil
Flags: blocking1.9.0.2?
> "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)$)"
Reached out to Adobe contacts, awaiting response.
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
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?
Flags: blocking1.9.0.2? → blocking1.9.0.2-
Assignee: bhashem → morgamic
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.
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.
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?
the qt blocklist bug mentioned that we don't have support for blocklisting plugins in ff2 ....
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]\.".
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?
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.
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.
Mike and Mike - do we want to bury the hatchet???
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!
Summary: Consider blocklisting vulnerable versions of flash → Blocklist vulnerable versions of flash
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.
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.
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?
> 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"
(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).
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.
(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.
We should be doing both, and we are. Not much argument to be had there.
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. ;)
(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.
(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)
Is Flash 10 available for OS X on PPC?
(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.
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.
Blocks: 496630
Discussion has since continued in bug 526019. Please go there.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.