Closed Bug 526019 Opened 12 years ago Closed 9 years ago
Blocklist vulnerable versions of flash for Firefox
This was discussed from the plugin awareness security review, that we should probably blocklist all vulnerable versions of the flash plugin for the 3.6Betas. This way we can test the startup page to be triggering our beta users with outdated flash versions to update to the latest upon firstrun. BuildID is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1. ** adjust for other supported platforms as well.
Could we fast-track this before the next beta is cut?
With the new plugin checking feature "blocklist" is ambiguous. Do you want them marked "outdated" (severity=0) to test that new feature, soft-blocked, or blocked outright? I assume this is about the new severity=0 feature. The blocking should be limited to Firefox version 3.6b. We should probably also not simply block things below 10.0 r32 but will have to allow for the most recent patched 9.x version as well. Since the new "update your plugin" feature does not use the pfs2 service directly I assume someone has to enter this data specifically into the blocklist database. I don't know who does that, but I bet morgamic does: assigning to him so he can reassign to the right person. This should not only block firefox 3.6, it needs to be done in time to get feedback.
Assignee: nobody → morgamic
It's possible to have two entries with separate version ranges: 1. 9.x -> 9.whatever 2. 10.x -> 10.whatever The blocklist uses regexes so this is going to be easier than people estimate for plugins.
This is all server side, right?
Michael, is this on your side of the court? 3.6Br2 shipped there hasn't been an update.
We should definitely get this done ASAP to test it using Firefox 3.6b2.
Flags: blocking-firefox3.6? → blocking-firefox3.6+
We've now shipped two more betas and bearing down on rc -- if we don't test this week it's not going to be a "test", it's going to be throwing this live to millions of people.
FWIW, i've tested the severity=0 firefox logic pretty well with test plugins. I've signed off of feature testing on the feature. So if there's any issues with how AMO responds to sev 0 blocklisting, we can expectantly narrow any problems to server side. Tracking bug for the firefox work is bug 514327.
It seems like this is the last week we might want to test this before the end of the year, and still have people around to respond.
I think we should: hard-block: the known vulnerable version(s) of Flash soft-block: the known crashy version(s) of Flash cc'ing Cheng as I think the most recent version is known unstable on gmail, or something?
Really, just sort of seems like the short path to victory is blocklist these ranges: * 9.0 <= version < 184.108.40.206 * 10.0 <= version < 10.0.42.34 This creates some issues with multiple operating systems, though. I'm trying to figure out which latest version maps to which platform and how to make these blocklist entries platform-specific.
(and yes, this is server side so can do any time)
Summary: Blocklist vulnerable versions of flash for Firefox 3.6 betas → Blocklist vulnerable versions of flash for Firefox
There has been some discussion out of band via email, so here's where we're at: 1. testing this on just a recent beta is insufficient testing 2. using version ranges for plugin blocking will have mixed effects on different firefox versions (some 3.0.x versions don't support it) 3. the push now is to not "hard block" anything but to "soft block" versions with known security problems What we need is to test behavior on these combinations of client + plugin so we can make a decision: 1. Firefox 3.0.* <= 3.0.6 with Flash < 9.0.x 2. Firefox 3.0.* <= 3.0.6 with Flash current 3. Firefox 3.0.* >= 3.0.6 with Flash < 9.0.x 4. Firefox 3.0.* <= 3.0.6 with Flash current 5. Firefox 3.5.x with Flash < 9.0.x 6. Firefox 3.5.x with Flash current 7. Firefox 3.6 with Flash < 9.0.x 8. Firefox 3.6 with Flash current As far as data, we should be able to confidently estimate: 1. how many 3.0.x users we have and what versions of Flash they are using 2. how many 3.5.x+ users are using Flash and what versions 3. how many users of Flash are using outdated versions (the above can be estimated via mozilla.com traffic?)
(In reply to comment #15) > 1. testing this on just a recent beta is insufficient testing This was filed during the beta period so we could test this new feature. Now it's well past release and we don't even have the luxury of testing during beta. We still need to do it, so test the best we can. > 2. using version ranges for plugin blocking will have mixed effects on > different firefox versions (some 3.0.x versions don't support it) Each version of the client requests a separate blocklist URL. Different plugins obviously crash in some versions vs others (e.g. lots don't crash 3.0 but do in the 3.5 released after the plugin) which is why we're using different URLs. The server needs to support that, just as AUS does. > What we need is to test behavior on these combinations of client + plugin so > we can make a decision: Which "we"? WebDev? WebDev QA? Client QA? Is it currenty being tested? (or maybe it's already done in the past week?) If it's not being tested does the group that's supposed to be doing the testing know that this bug is waiting on them? What is preventing it? We've been trying to blocklist flash in some form since 2008 (see bug 436348, duped to this bug which was originally just about using the severity=0 "update needed" feature added with Firefox 3.6 -- and wanted to make sure we had end-to-end support for using that severity with Firefox 3.6 without affecting other versions of Firefox.
Bravo, Dan. Mission accomplished.
Dan - sorry about comment #17; that wasn't a real winner. Not very constructive on my part. Should have been something like this: - Mike, Nick and I met on Thursday - sorted out some process issues - "we" in this case should be client QA or whoever can do this, but Mike wants screenies of these cases first so we understand the impact; he'll probably comment I understand your frustration with these bugs. I don't agree with the points you made in 1 or 2. For 1, that's just one version and unless we made broader changes for the service (see point 2) it's just not an appropriate testbed. For 2, that's not the spec the service was given and if you are saying we should change requirements that's fine -- otherwise I'm not clear why the blocklist.xml definition has targetApplication and subsequent version ranges. Even then, I don't think it's really fair or wise to demand we change that on the fly at this time. Either way, Mike insists we understand those cases and complete the tests in comment #15. I think we'll learn what we need to learn from those. Mike B can follow up with the who and when. *handoff* Go!
Quite right; to be clear, I am personally unclear on: - what the various "levels" of blocklisting are available for plugins and add-ons in Firefox 3.5.x and 3.6.x - what the UI effects of those levels are in each of the products Before we go a' blocklisting, we need these to be clearly documented. If someone can point me to documentation and tell me that the effects of the blocklist have been verified, I'll happily go away. To date, though, nobody's been able to give me a clear and confirmed picture. I assert that we need to know the effect of a change before making it :)
Assuming the user hasn't changed the extensions.blocklist.level pref severity 3.6 3.5 3.0 (severity ignored) 2 hard block hard block hard block 1 soft block soft block hard block 0 outdated soft block hard block FF 3.0 ignores severity and only knows about hard blocks. FF 3.5 and 3.6 treat everything equal or above the pref (2) as a hard block. FF 3.5 treats everything else (0,1) as a soft block, FF 3.6 first checks for the magic "outdated" value 0 before treating everything remaining (1) as a soft block.
We already have several Flash blocks in place and a blocklisting policy. See https://wiki.mozilla.org/Blocklisting/PluginBlocks and related bugs for more info.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.