![[Steve Friedl Logo]](/images/unixwiz-logo-140x80.gif){kind=logo}
This site uses advanced css techniques
Internet Explorer has had a long reputation for being insecure, and much of
this criticism has historically been entirely deserved (though less so
lately). One area of particular criticism has been IE's support
for ActiveX.
This is widely hailed as one of the worst features of IE, and the fact that no other major browser supports ActiveX is seen as an automatic plus in the security column for those other browsers.
This claim is literally true, but only in name: all useful browsers support multiple extension mechanisms, including those which allow for full code execution by the plugin via a DLL. Though there are differences (including ones that affect security), the similarities are far greater than the differences, and it's not entirely clear that IE is any worse at all in this respect.
In this paper we'll explore the extension mechanisms of two major browsers, Internet Explorer 6 and Firefox 2, and see that there's more in common that it seems. Though Firefox is a cross-platform product, our main focus is on the Windows implementation where it can be contrasted properly with IE.
We are considering IE6 on XP/SP2 — this is a mature platform — and we are not considering IE7: IE7 is superior from a security point of view, and we'd rather make our case with the more widely deployed (and criticized!) platform of IE6.
At its core, IE requires executable code for all meaningful extensions, and in this respect presents a more consistent (though more difficult to develop) mechanism. Though extensions are often identified simply as "ActiveX Controls", they can actually take multiple forms internally as they serve different purposes.
There is a somewhat blurry line between these various categories, mainly because they all share a common programming interface, but all of them bear executable code. Any can be used for good or nefarious purposes.
Firefox is a very popular Open Source browser with good cross-platform support, and it's widely viewed to be more secure than IE.
Firefox supports two broad categories of add-ins: extensions and plugins. They are related, but separate. We'll discuss both.
Extensions are used to produce an enormous variety of useful utilities that enhance the browsing experience. A whole industry has sprung up around these extensions, including some incredibly popular efforts such as Greasemonkey (for customizing pages you're viewing) and Web Developer (for supporting HTML/CSS coding).
Most Firefox extensions are written in XUL and Javascript. XML User Interface Language (XUL, pronounced "zool") is used for creating user interfaces, and the browser itself uses XUL to define how it behaves. XUL works hand in hand with Javascript (and HTML and CSS), and is sufficiently powerful to perform the great-bulk of add-in activities.
XUL, Javascript, HTML, and CSS are all fully sandboxed, which dramatically limits what they can do outside the browser. There are provisions for extensions to interact with the filesystem and other system objects, but they are limited.
But some tasks simply require more integration with the operating system than Javascript and XUL can provide, so some extensions include XPCOM Components.
XPCOM is the Cross-Platform Component Object Model, and it's designed to provide a modular software framework. It's provided in binary object form (a DLL for Windows, a shared object for *ix), and in this respect runs with full access to the underlying operating system.
When an XPCOM component is used, it's virtually always accompanied by other extension pieces (Javascript, XUL, HTML, CSS, images, etc.) in an .XPI installation bundle.
We'll touch on the installation mechanisms later.
Somewhat different from extensions are plugins, which assist with more specific media rendering rather than the broader functionality provided by Javascript or XPCOM.
Plugins are typically much larger efforts and support features recognized by anyone who's surfed the web for any amount of time:
These are always provided in binary formats (DLL or .so) rather than Javascript/XUL, and are rarely open sourced. Because they are executable, they can do anything a .EXE can do as the user running the browser. They do not usually include extension-like accessories (Javascript, XUL, or the like).
Plugins are usually associated with software running outside of the browser — such as the Adobe Acrobat reader — so the plugin are sometimes little more than "glue" linking the browser with the real application.
It appears that plugin installation is accomplished by the larger application installer dropping a DLL in the plugins\ directory, and it serves as the bridge between the browser and the application core - they are loaded at startup.
It's clear that add-ins aren't going to be useful until they're installed, and in the past this had been a weak point of IE: the drive-by install. When malware can install itself without clear notice and approval, then the user really has no hope of a safe and secure surfing experience.
Both browsers support installing of extensions from within the browser enviroment itself, plus running a .EXE with a traditional installer. We're only discussing the former, because the latter always involves an intentional act outside the scope of control of the browser.
Firefox provides a consistent interface for installing extensions via a .XPI file: these are simply ZIP archives that expect to have an install.js Javascript file to drive the installation.
Examining one popular web-development extension,
Aardvark,
we can look inside the XPI with the standard Linux unzip
program to see what's there (we've omitted 19 Mac OS-related files
for brevity: XPI is a cross-platform installer), along with the
prompt provided by Firefox when installing it:
$ unzip -l aardvark-2.0-fx.xpi
Archive: aardvark-2.0-fx.xpi
Length Date Time Name
-------- ---- ---- ----
270 12-14-06 17:22 chrome.manifest
0 12-14-06 17:57 content/
6148 12-14-06 17:52 content/.DS_Store
560 08-04-06 18:05 content/aardvark.gif
13596 12-14-06 23:05 content/aardvarkCommands.js
4713 12-14-06 18:01 content/aardvarkDBox.js
1929 07-26-06 16:29 content/aardvarkhelp.gif
13452 12-14-06 23:49 content/aardvarkMain.js
3872 12-12-06 21:45 content/aardvarkUtils.js
222 07-26-06 17:59 content/closedbox.gif
1314 12-14-06 17:31 content/firefoxOverlay.xul
0 12-14-06 15:22 defaults/
0 12-14-06 15:22 defaults/preferences/
158 12-14-06 19:50 defaults/preferences/aardvark.js
879 12-16-06 14:22 install.rdf
0 12-14-06 15:22 locale/
0 12-14-06 15:22 locale/en-US/
225 12-14-06 17:53 locale/en-US/aardvark.dtd
139 12-14-06 17:54 locale/en-US/aardvark.properties
0 12-14-06 17:48 skin/
6148 12-14-06 17:48 skin/.DS_Store
242 12-14-06 18:39 skin/overlay.css
188 08-07-06 16:40 skin/toolbar-button.gif
Installation happens quickly, and after restaring the browser, the features of Aardvark are available (once started, hovering over a block-level element reveals the properties of that element).
No executable code is included in Aardvark.
Turning to a second example, Tab
Effect, we see a very small XPI file (~40kbyte) that nevertheless contains
an XPCOM component to supports its operation:
$ unzip -l tab_effect-1.1-fx.xpi
Archive: tab_effect-1.1-fx.xpi
Length Date Time Name
-------- ---- ---- ----
113 01-02-07 06:33 chrome.manifest
0 01-08-07 06:30 components/
216 01-11-07 06:31 components/ITabEffect.idl
167 01-11-07 06:31 components/ITabEffect.xpt
94208 01-11-07 06:31 components/tab_effect_xpcom.dll
0 01-09-07 08:31 content/
306 01-08-07 04:20 content/browser.xul
896 01-08-07 06:09 content/config.xul
982 01-09-07 16:34 content/javascript.js
814 01-09-07 07:19 install.rdf
-------- -------
97702 10 files
The installation process is identical, and no indication is given that this extension contains executable code.
Plugins, on the other hand, do not go through this mechanism, and it does not appear that Firefox is directly involved in the installation process at all. Instead, the application providing the plugin does all the work during its installation process, with the plugin being just one part of the process (dropping the DLL into the plugins\ directory).
We'll note that Firefox may well serve as the vehicle for installation (by downloading and running a .EXE or .MSI installer), but it's not generally aware that the installer is going to have any effect on Firefox. Instead, it's just providing a generic download-and-run service.
It appear that Firefox is entirely uninvolved/unaware of plugin installation until it restarts and finds the DLL in its plugins\ directory.
We have not found a way to disable a plugin save for going to the directory and moving or removing the DLL (as of Firefox 2.0.0.2).
Installation of IE addins is done either by ActiveX control (via the browser itself),
or by running an executable installer (.EXE), which works outside the browswer
environment. What's important is that all addins bear executable code.
IE6 in XP/SP2 introduced a much more restrictive (and consistent) environment environment for installing ActiveX controls, requiring usually two separate user actions to approve one. This starts with the "gold bar" that appears at the top of the browser window.
Many web pages that wish to install an ActiveX control include detailed instructions, as we can see here: though the highlighted gold bar at the top is provided by IE, the rest of the page is standard HTML hosted by the webserver. This example is clearly attempting to help the user install the control (for good or for bad).
In order to actually install the control, one must right-click the gold bar and select Install ActiveX Control, as illustrated on the web page providing the control.
But for most ActiveX controls, there's another step — the Security Warning confirmation. This dialog box provides the name of the control, the publisher, and links to more information.
Only after clicking [Install] is the component given a chance to run.
There are exceptions to the security warning dialog box: a user can whitelist controls from particular vendors ("Always install software from Fun Web Products"), and they can be blacklisted as well.
We'll note that even for .EXE-based installers, a similar gold bar warning appears as well, making it difficult for software to make it onto the machine without notice.
Once an add-on has been installed (via whatever mechanism), all browsers provide for at least some level of management or maintenance from within the browser environment itself, though perhaps not comprehensively.
Here we visit the mechanisms by which a user can control the add-ins.
Firefox provides an nice manager via the Tools » Add-ons
menu, and it shows all the extensions currently loaded, as well as
the ability to uninstall or disable each one. Plugins from a previous
upgrade that are no longer compatible are shown in their disabled state
and allow for removal or upgrade.
A helpful link brings you to the central Mozilla site for all extensions, allowing for finding new and interesting add-ons.
This interface also provides actual interaction with the extension via an Options button (if supported by the extension itself). This is a convenient, centralized configuration mechanism.
It's not apparently, however, just what goes into this extension or whether it includes a code-bearing DLL or not.
In addition, plugins do not show up here: they are found only in the URL about:plugins, producing a page which looks like:
But this is a readonly display: actually removing the plugin cannot be done from within Firefox. Instead, one must navigate via Explorer and delete or move them manually. We found this very surprising.
Prior to XP Service Pack 2, IE provided no real way to find out which add-ins were loaded, and this made it easy for malware to hide and maddeningly difficult to track down.
But with XP/SP2, IE6 now provides a full-fledged management control panel via the Tools » Manage Add-ons... menu option, and it provides complete exposure to every possible kind of add-in.
Unlike Firefox, this is a one-stop shop for addin management. We don't believe it's possible to extend IE without it showing up here, and it includes the name of the code-bearing DLL, a remarkably helpful feature when trying to figure out what that unknown DLL is used for.
In addition, all kinds of add-ins can be disabled from this control panel, including things like Acrobat, Quicktime, and Java. Firefox provides no mechanism to do this.
One minor nit: it doesn't seem possible to resize the management dialog box, which is never big enough, so we end up doing lots of scrolling around. Firefox's management box is resizable.
We take the position that code-bearing add-ons are more dangerous than those without an executable component, and this is a distinction we believe should be made more strongly.
We can make these general observations:
Firefox doesn't distinguish between code-bearing extensions and those that are merely Javascript/XUL, either during installation or management, and this strikes us as an appalling oversight. We strongly believe that DLL-based extensions ought to require higher trust or scrutiny than those based on sandboxed languages, and the user is given no real choice on this front.
IE doesn't need to make this distinction because all extensions are code-bearing, but it provides much more information about the particulars of each one.
After researching this in some detail, we are surprised by the weaknesses of the Firefox model. Though ActiveX has been decried as the worst part of IE, and should be eliminated from the browser entirely, we fail to see how it's really that different in Firefox - both provide mechanisms to extend the browser in useful (and not useful) ways.
Prior versions of IE have been prone to "drive-by" installs, and we certainly believe that allowing the bad guy to install and run a DLL without user interaction is a security abomination. We understand that this has been more or less completely addressed by IE 6 in XP/SP2.
Unsophisticated users are much more likely to be victims of their own ignorance (purposely installing software that ends up being malware), and this can happen with any browser having an extension mechanism.
But a thoughtful and educated user is likely to be just as safe using either one, so one ought to choose his/her product based on features, not security.
First published: 2007/07/01
![[Steve's Email]](/images/steve-email.gif)
![[RSS Feed available]](/images/feed-icon-14x14.png){kind=icon}