Firefox 3.6/AboutSupport Security Review

Overview

Create an in-content (non-web-accessible) about page that support (both SUMO and third party tech support) can use to help users with problems.

Should include basics like profile location, OS, buildID as well as details like installed addons and plugins, values of certain prefs, etc. to help debug user issues.

Background links

• Firefox/Projects/about:support

• 367596: Create about:support page with troubleshooting information (e.g. list of extensions)
• 516616: Add an "Installation History" section to about:support.
• 516617: Add an "Update History" section to about:support.
• 518601: Troubleshooting Information page should not allow copy-and-paste of the profile directory.
• 518606: Troubleshooting Information page should have better support for copy-and-paste to plaintext.
• 518607: Move the Troubleshooting Information page into toolkit so other apps like Thunderbird and SeaMonkey can use it.
• 518989: Themes cannot give about:support an original design
• 519077: Do something about the modified prefs list on about:support (remove it, only display certain items, or add some type of warning)

Security and Privacy

• Is this feature a security feature? If it is, what security issues is it intended to resolve?
  • This feature is not a security feature.
• What potential security issues in your feature have you already considered and addressed?
  • We no longer show the profile directory path in the page. We have also introduced a preferences whitelist so we only display prefs that are useful and don't pose a serious risk to the user's privacy.
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • Missing prefs would actually reduce the risk posed by this feature. A hacked whitelist could pose some interesting implications, but if an attacker can hack the whitelist, they can probably do far more direct damage.
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • This feature has fairly serious privacy implications. The contents of the about:support page could get pasted into publicly accessible and searchable Internet content, such as support forums. Each piece of information displayed in the page needs to be evaluated for privacy implications.
• How are transitions in/out of Private Browsing mode handled?
  • Shouldn't matter.

Exported APIs

This feature does not export any interfaces in the programmatic sense. The biggest exposure surface is simply the page contents themselves since they may often get pasted into publicly accessible and searchable internet content (e.g. support forums).

Module interactions

The about:support page relies on a number of high-level application features (notably application preferences). These features are pretty obvious from the contents of the page. See the output format section below.

Data

There is a direct correspondence between the data read by this feature and the output format, see below. This feature does not store any data of its own.

The about:support output format

Application Basics

• Name, e.g. "Firefox"
• Version, e.g. "3.7a1pre"
• Profile Directory, (just a button to open the profile directory)
• Installed Plugins (just a link to about:plugins)
• Build Configuration (just a link to about:buildconfig)

Extensions

• Name, e.g. "Firebug"
• Version, e.g. "1.4.3b1"
• Enabled ("true" or "false")
• ID, e.g. "firebug@software.joehewitt.com"

Modified Preferences

Only preferences that are modified (i.e. have a "user value") and are also on the whitelist are shown.

The current whitelist is:

 // We use a preferences whitelist to make sure we only show preferences that
 // are useful for support and won't compromise the user's privacy.  Note that
 // entries are *prefixes*: for example, "accessibility." applies to all prefs
 // under the "accessibility.*" branch.
 const Whitelist = [
   "accessibility.",
   "browser.fixup.",
   "browser.history.",
   "browser.link.open_newwindow",
   "browser.link.open_newwindow.restriction",
   "browser.mousewheel.",
   "browser.places.",
   "browser.startup.homepage",
   "browser.startup.homepage_override.mstone",
   "browser.tabs.",
   "browser.zoom.",
   "dom.",
   "extensions.checkCompatibility",
   "extensions.lastAppVersion",
   "font.",
   "general.useragent.",
   "gfx.color_management.mode",
   "javascript.",
   "keyword.", 
   "layout.css.dpi",
   "network.",
   "places.",
   "print.",
   "privacy.",
   "security."
 ];

Reliability

The feature is very simple, and involves minimal user interaction. The about:support page can be invoked by typing about:support in the location bar or selecting Troubleshooting Information from the Help menu. The page will be generated without any further interaction from the user.

The only other user interaction is the user may press the "Copy all to clipboard" button. This is similar in effect to just selecting all and typing Ctrl/Cmd-C. The button differs in that it only copies the text below the button and the plain text copied to the clipboard is formatted differently than if the regular select/copy mechanism is used.

Configuration

The only real configuration for this feature is the whitelist in browser/base/content/aboutSupport.xhtml. This whitelist will need to be updated with new prefs as the support group discovers prefs that are useful for troubleshooting These could be new prefs added to the product or existing prefs that are not now whitelisted but which are discovered to be useful in the future. Existing prefs in the whitelist may also be dropped because they are dropped from the product, or they are determined to reveal too much user information, or just because they are recognized to not be all that useful.

Relationships to other projects

This project is not related to other projects in the community.

Review comments

• The pref-truncating code should check that it's not truncating on half a surrogate pair
• Are there problems with the length calculation on calls to setTransferData in the presence of Unicode surrogate pairs?
  • transferable.setTransferData("text/html", ssHtml, dataHtml.length * 2);
  • transferable.setTransferData("text/unicode", ssText, dataText.length * 2);