526019 - Blocklist vulnerable versions of flash for Firefox

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Tony Chung [:tchung]]

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.

Comment 1

[juan becerra [:juanb]]

Could we fast-track this before the next beta is cut?

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[Michael Morgan [: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.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

This is all server side, right?

Comment 5

[juan becerra [:juanb]]

Michael, is this on your side of the court? 3.6Br2 shipped there hasn't been an update.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

We should definitely get this done ASAP to test it using Firefox 3.6b2.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Helllloooooooooooooooooooooooooo?

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Tony Chung [:tchung]]

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.

Comment 10

[chris hofmann]

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.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 12

[Michael Morgan [:morgamic]]

Really, just sort of seems like the short path to victory is blocklist these ranges:

    * 9.0 <= version < 9.0.115.0
    * 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.

Comment 13

[Michael Morgan [:morgamic]]

(and yes, this is server side so can do any time)

Comment 15

[Michael Morgan [:morgamic]]

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?)

Comment 16

[Daniel Veditz [:dveditz]]

(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.

Comment 17

[Michael Morgan [:morgamic]]

Bravo, Dan. Mission accomplished.

Comment 18

[Michael Morgan [:morgamic]]

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!

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

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 :)

Comment 20

[Daniel Veditz [:dveditz]]

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.

Comment 22

[Jorge Villalobos [:jorgev] (he/him)]

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.