Firefox3.6/Plugin Update Awareness Security Review
Contents
Overview
Automatically detect when an installed plugin is concidered out of date, and alert the user - directing them to the Plugin Check page on mozilla.com.
- Background links
Security and Privacy
- Is this feature a security feature? If it is, what security issues is it intended to resolve?
Yes - Outdated plugins are often vulnerable and unstable. They are also very common, as users had to manually check each plugin version and find the newest version to install. This feature automatically detects outdated versions and offers an upgrade path.
- What potential security issues in your feature have you already considered and addressed?
To show the notification bar, the browser (chrome) listens for certain events coming from content - potentially allowing content to generate an event that would trigger a chrome notification bar. Events that are not trusted events are ignored.
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
No.
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
This uses (and integrated into) the architecture provided by the Blocklist functionality - any weakness in the blocklist code may be present in this feature.
- How are transitions in/out of Private Browsing mode handled?
Private Browsing mode is not relevant to this feature.
Exported APIs
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
Adds function: nsIPluginHost.getPluginTagForInstance() - only available to C++ XPCOM
Adds constant: nsIBlocklistService.STATE_OUTDATED
- Does it interoperate with a web service? How will it do so?
Yes - it uses the data from the blocklist.xml file, generated by the Plugin-finder service on addons.mozilla.com
- Explain the significant file formats, names, syntax, and semantics.
No schema change to blocklist.xml. A '0' value of the severity attribute is now interpreted as marking the plugin as outdated.
- Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
Yes - comments in the .idl files.
- Does it change any existing interfaces?
Yes - nsIPluginHost and nsIBlocklistService.
Module interactions
- What other modules are used (REQUIRES in the makefile, interfaces)?
No additional interactions that weren't already in the existing blocklist functionality.
Data
- What data is read or parsed by this feature?
The severity attribute in blocklist.xml - all other parsing and reading comes from the blocklist functionality.
- What is the output of this feature?
No output.
- What storage formats are used?
blocklist.xml (stored in the profile directory) was handled already by the existing blocklist code.
Reliability
- What failure modes or decision points are presented to the user?
When an outdated plugin is loaded in content, the user is warned and given the choice of visiting the Plugin Check page, or ignoring the warning.
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
N/A
Configuration
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
The URL of the Plugin Check page is stored in the pref plugins.update.url. A pending warning on restart is stored in the pref plugins.update.notifyUser and set/reset automatically. Neither pref has a UI.
- Are there build options for developers? [#ifdefs, ac_add_options, etc.]
No.
- What ranges for the tunable are appropriate? How are they determined?
N/A
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
The database backing the Plugin-finder webservice (that generates the blocklist.xml file) needs to be kept up to date with what versions of common plugins are considered outdated.
Relationships to other projects
- Are there related projects in the community?
No.
Review comments
- concern that some plugin installers include foistware.
- how can we put pressure on plugin vendors to provide clean installers? warn users as they leave mozilla.com for bad vendors?
- how many lists of plugins/versions do we have, between PFS and the plugincheck website and the blocklist?
- do we show the infobar for both "just outdated" and "outdated and has security holes"?
- We're constrained to "outdated", "softblock", and "hard block" :( So it's hard to block an old version while also letting users know there's a newer version available.
- Almost want multiple dimensions replacing "levels": does this outdated version have security vulnerabilities; does mozilla think it should be blocked; is there a new version available.
- is there a pref for "automatically disable outdated plugins" for our more paranoid users?
- There's a threshold pref, extensions.blocklist.level. Setting it to 0 should make "outdated" plugins get disabled.
- is the blocklist transferred to users in a way that's authenticated, or it is vulnerable to MITM?
- The default plugins.update.url is on https://www.mozilla.com/, but who knows what Ubuntu's is
- since the warning is an infobar, can users tell the difference between our feature (sending them to adobe.com) and a malicious advertisement (sending them elsewhere)?
- Clicking "there is a newer, safer version available" actually takes you to mozilla.com plugincheck page, which as of firefox 3.6, has access to full version number information!
- i shouldn't have to load a page that uses java to find out i have an outdated java. firefox should check for me once a week.
- can we avoid making this be the first experience right after updating to firefox 3.6?
with some redundancy of the above list:
- does webdev know they need to populate blocklist.xml
- need to send different blocklists to different versions -- we don't support severities in Firefox 3.0 and don't want to block "outdated" ones. Is the server side currently able to do this?
- There's a level pref to let users automatically block outdated plugins if they want (or no blocking at all).
- who maintains this list? We need a process, and someone nominated to keep an eye on it.
- we need to collect the stats we get from the plugincheck page. This will be a sensitive topic and we need to anonymize the data, but plugin totals would help us find new plugins we need to worry about.
- Can the plugin check page handle the traffic that an outdated plugin will throw at it? e.g. Flash updates
- worry: adding a legit infobar that leads to a place to download stuff adds to the worry about evil sites spoofing that infobar leading to their own spoof site.
- when do we start to populate the blocklist for ship? On initial ship (do we want that to be people's first experience?)? Or rolled out sometime later?
- we absolutely need to test this in beta. Perhaps flag old Flash and WPF and restrict the app version to just 3.6b1 for now.
- We'll show the plugincheck page on startup once after some plugins are marked outdated. If the user has visited the page from the infobar warning that should cover it.
- Did I mention that we need a process?
