Mozilla's Firefox has a reputation for being not only a great browser, but a highly secure one as well. Many organizations that don't rely on Internet Explorer or ActiveX technologies are being urged by this reputation to switch to Firefox, both for safety's sake and for ease of use.
That doesn't mean Firefox is immune from bugs or security holes, however, and since the release of 1.0, Mozilla has provided a number of incremental upgrades designed to close security holes in Firefox. As of this writing, the most recent version is 1.0.6, which fixes (among other things) several severe arbitrary code-execution exploits.
How, then, should an administrator keep on top of the most recent versions of Firefox and ensure that it's up to date throughout an organization?
There are two basic ways to do this: one is when the management of individual desktops is left to the users themselves (the "power user" scenario); the other is when software installations are handled by administrators, and the end users are only allowed to run programs, not install them (the "Joe User" scenario).
1. Power users
By default, Firefox is set to check once a day if there is a new version of either its core program or any of the installed plug-ins or add-ons. When Firefox is checking for updates, a green arrow appears next to the "throbber," the graphic icon in the upper-right-hand corner of the browser that flashes when a page is loading. If a user clicks on the green arrow, then Firefox downloads the newest version of the program. Before installing it, Firefox will prompt the user to close the browser. In short, power users can be trusted to do their own upgrades and installs when necessary.
For an experienced user, this sort of work is effortless, of course. But if you're in an environment where you don't want the users to install their own applications, things become more complicated.
2. "Joe Users"
Firefox was written as a cross-platform application, so it doesn't come with an automated way in Windows for a central authority to force upgrades or even deploy the product across an organization. That has been cited as one of Firefox's biggest present-time drawbacks. It also encompasses problems such as locking down the user from making changes to the program's settings -- since many of Firefox's settings are not stored in the Registry, but are held in text files.
There are a few third-party answers to these problems. The best and most comprehensive solution comes courtesy of FrontMotion, which has created a set of Mozilla Firefox MSI installers. There are MSIs (Microsoft Installer packages) for each major iteration of Firefox, along with accompanying instructions for distributing the MSI in a network environment. MSI packages have a number of built-in advantages: one, they're in the distribution format favored by most admins in the first place; two, they can detect if there's already an instance of Firefox running and prompt for it to be shut down before an upgrade.
Even better, FrontMotion also has a community edition of Firefox -- a custom build of Firefox that has been designed to allow administrative lockdown through Active Directory settings. This is probably the best place to start if you want to deploy Firefox in an organization and rely on existing mechanisms for administration instead of ad hoc solutions. It's not clear yet if Firefox itself will have AD lockdown features as a standard option so, currently, FrontMotion remains the only choice for such things.
Another possibility, Bob Templeton's FFDeploy script package, is more configurable but has not been maintained as aggressively. It uses a VBS script that can be modified by the administrator as needed to deploy an "image" of Firefox. It's a less comprehensive solution, since it ignores many of the complications that arise when deploying Firefox in a managed environment.
Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
More information from SearchWindowsSecurity.com
This was first published in September 2005