Open Bug 565398 Opened 9 years ago Updated 5 years ago

Plugincheck should suggest disabling plugin when current version is vulnerable and no update is available (for everyone or for the user's OS)

Categories

(Websites :: plugins.mozilla.org, enhancement)

enhancement
Not set

Tracking

(Not tracked)

REOPENED

People

(Reporter: joe, Unassigned)

References

()

Details

(Keywords: sec-want, Whiteboard: https://docs.google.com/document/edit?id=1NYGO146JkYwE0voIH09fMAvF54krQUr_p-Exh87NM8M&hl=en)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20

Plugincheck should check operating system version in determining if plugins 
should be updated; in some cases, the most recent version available for 
older operating systems (such as Mac OS X 10.3) may be an older version. If
this is the case, it is misleading/confusing to tell users to update when
no update is available.

Similarly, Java for Mac OS X is provided directly from Apple, and frequently
lags releases for most other platforms. Again, while it is correct that the
version installed may be out of date, regretably a more recent version may not
yet be available.

Reproducible: Always

Steps to Reproduce:
1. On a Mac running 10.3.9 and Firefox 2.0.0.20 and the most recent versions of
Quicktime, Java and Shockwave, visit http://www.mozilla.com/en-US/plugincheck/

Actual Results:  
Quicktime, Java snd Shockwave are flagged as "outdated version" and the 
"update" button is present.

Expected Results:  
Since the most recently available versions of those plugins for OS X 10.3 are
still too old, something other than "update" should be suggested (e.g., update
your OS, deinstall those plugins, or whatever)

I've ticked the security problem box below, because obviously this highlights a
security vulnerability that is present for older versions of these plugins.
Doesn't need to be private, the vulnerabilities are well-known. The ultimate answer here is that plugin check, in these cases, should warn you that the plugins are unsafe, and ask you to disable them completely if there is not an updated version. Running Java in Firefox on OSX10.3 will get all your data stolen pretty efficiently.
Group: core-security
Component: Other → www.mozilla.com
Product: Plugins → Websites
QA Contact: other → www-mozilla-com
Component: www.mozilla.com → plugins.mozilla.org
QA Contact: www-mozilla-com → plugins-mozilla-org
Running 2.0.0.20 is unsafe, too. The only thing saving you is no one is bothering to create/deploy exploits for it as far as we can tell (plugins make a more attractive target, apparently). But the vulnerabilities are definitely there.
Assignee: nobody → ozten.bugs
Depends on: 571145
Target Milestone: --- → 1.1
We should show a vulnerable warning extra messaging on why the user is vulnerable. Will write specs.
Assignee: ozten.bugs → rdoherty
Duplicate of this bug: 570363
Duplicate of this bug: 573848
Specs in whiteboard.
Assignee: rdoherty → ozten.bugs
Whiteboard: https://docs.google.com/document/edit?id=1NYGO146JkYwE0voIH09fMAvF54krQUr_p-Exh87NM8M&hl=en
Target Milestone: 1.1 → 1.2
I'm assuming that since we have specs, a target milestone, and an assignee, it's safe to confirm this bug :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
As far as I can tell this fix is 2 parts:

1) Add a yellow fade effect whenever someone clicks the #howto-disable anchor.

2) Data updates that match old platforms to mark them vulnerable.

Is this correct?
(In reply to comment #8)
> As far as I can tell this fix is 2 parts:
> 
> 1) Add a yellow fade effect whenever someone clicks the #howto-disable anchor.
> 
> 2) Data updates that match old platforms to mark them vulnerable.
> 
> Is this correct?

Correct sir!
Target Milestone: 1.2 → 1.3
Target Milestone: 1.3 → 1.2
Added click and yellow fade for #howto-disable

r72272

@rdoherty Note: Data updates are still needed, thanks!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I updated Java 1.4.2 on OS X 10.3 to 'should be disabled'. Hard to test without an old mac though.
This bug is still not fixed: on Mac OS X 10.4.11, Software Update says: "Your software is up to date." but http://www.mozilla.com/en-US/plugincheck/ says "Outdated Version" for:
* Java Embedding Plugin 0.9.7.2
* Java Plug-in
  Java 1.3.1 Plug-in
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #13)
> This bug is still not fixed: on Mac OS X 10.4.11, Software Update says: "Your
> software is up to date." but http://www.mozilla.com/en-US/plugincheck/ says
> "Outdated Version" for:
> * Java Embedding Plugin 0.9.7.2

This happens on my Intel Mac OS X 10.6.4 too. The database provides wrong info to Mac users. See Bug 587002.
mmm, see Bug 565398.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> This bug is still not fixed: on Mac OS X 10.4.11, Software Update says: "Your
> software is up to date." but http://www.mozilla.com/en-US/plugincheck/ says
> "Outdated Version" for:
> * Java Embedding Plugin 0.9.7.2
> * Java Plug-in
>   Java 1.3.1 Plug-in

I've added 1.3.1 and 0.9.7.2 as 'should be disabled' for OSX 10.4. Let me know if that works.
(In reply to comment #16)
> I've added 1.3.1 and 0.9.7.2 as 'should be disabled' for OSX 10.4. Let me know
> if that works.

No, I still get "Outdated version" (and the "Update" button) for both.
Reopening for comment 14 / comment 17; Marcia, mind checking when you get a chance, please?  Thanks!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I assume people are using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8. I will attach a screenshot of what I see on 10.4 and 10.6 using Firefox 3.6.8. 

Basically on 10.4 I see what Vincent is seeing, and on 10.6 I see what Kohei is seeing.
The original bug was filed on 2.0.x - not sure if that one needs to be checked as well?
(In reply to comment #22)
> The original bug was filed on 2.0.x - not sure if that one needs to be checked
> as well?

Nah, Firefox 2.0.x isn't supported: http://www.mozilla.com/en-US/plugincheck/more_info.html
Encountered this today.  This is really bad form, as firefox points to the page on java, and java points at an apple doc telling you to run system update, and NEITHER OF THESE actually tell you if a newer version is available.

If we're unable to reliably get info on whether a newer version is availble, we need to say "unable to check", not report that we're out of date.
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: PowerPC → All
Just bumped into another example of this:

-- Mac OS X 10.5.8 for PowerPC running Firefox 3.6.15 (Mozilla/5.0 
   (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 
   Firefox/3.6.15 )
-- Plugin Check flags Shockwave Flash 10.1 r102 as potentially vulnerable
   and recommends "Update Now"
-- Following the "Update Now" link goes to 
   http://get.adobe.com/flashplayer/otherversions/
-- Selecting Macintosh OS X 10.4 - 10.6, the only option listed is
   Flash Player 10.2 for Mac OS X 10.4 - 10.6 (*Intel*) (emphasis added)

Plugin Check should either flag it as "Vulnerable, no update available"
or recommend "Vulnerable, uninstall" but shouldn't recommend "Update Now"
when no update is available for the architecture that's in use.

Thanks as always for your continued efforts on Plugin Check and this
specific issue -- in spite of flagging bugs from time to time, I think
this is a great tool for the community.
So, while this is very old I am sure most, if not all, these problems still in exist in some shape or form. My suggestion is the following.

As part of the rewrite/design we need to update and define our baseline in terms of support for browser(s), versions of these as well as OS versions. For anything below this, we simply do not do the detection and checking and instead inform the user that their browser/OS is out of date and is no longer supported by plugin check and suggest an upgrade.

With regards to the other issues raised with regards to supported OS version that have stale versions of a plugin and cannot update unless they update their OS, I agree we need to inform the user that these make them vulnerable to attack and suggest that they disable the plugin.

To ensure the code works as expected I am going to write tests that test these various scenarios and basically from there ensure that all tests pass as expected. I believe, and it is my hope ;), that this can be done without needing access to all the various OS versions and browsers by spoofing the calls.
Flags: needinfo?(stephen.donner)
Keywords: sec-want
Summary: Plugincheck suggests updates which aren't available/aren't yet available for older operating system releases → Plugincheck should suggest disabling plugin when current version is vulnerable and no update is available (for everyone or for the user's OS)
(In reply to Schalk Neethling [:espressive] from comment #26)
> So, while this is very old I am sure most, if not all, these problems still
> in exist in some shape or form. My suggestion is the following.
> 
> As part of the rewrite/design we need to update and define our baseline in
> terms of support for browser(s), versions of these as well as OS versions.
> For anything below this, we simply do not do the detection and checking and
> instead inform the user that their browser/OS is out of date and is no
> longer supported by plugin check and suggest an upgrade.

Sorry, Schalk - I don't actually have this information; I know the redesign has already happened, but maybe :tomcat has an idea of the supported-browser matrix?  (We used to follow the Yahoo!/Webdev one, but we haven't in a long while, I think.)
Flags: needinfo?(stephen.donner)
Assignee: ozten.bugs → nobody
You need to log in before you can comment on or make changes to this bug.