Closed Bug 442153 Opened 12 years ago Closed 12 years ago

add-on and extension attack vectors

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: ws, Unassigned)

Details

Email from reynaudd@loria.fr to the security alias:

Hello,

In a joint work with Philippe Beaucamps conducted at Loria's computer  
security lab [1], we came across what we consider to be problems with  
the security model of Firefox extensions. These problems do not rely  
on any particular bug in Firefox, just on documented features of  
Mozilla products implementing an extensions mechanism. However for  
obvious reasons, we focused on the security impact for Firefox users.  
Note that we are not the first to consider the impact of malicious  
Firefox extensions [2].


DESCRIPTION

We think that weaknesses in the lifecycle management of Firefox  
extensions combined with the power of APIs exposed through XPCOM  
components will lead to a proliferation of Firefox-specific malware,  
or rather that existing malware on Internet Explorer (using ActiveX  
and BHOs) will sooner or later be ported to Firefox. Here is a list of  
problems we identified with the management of extensions (it is  
probably not comprehensive, but all problems affect FF3 RC3) :

1. The integrity of signed extensions is not checked after  
installation. As a consequence, a rogue extension can infect an  
already installed signed extension without notification.
To reproduce it : modify any file in a signed extension. By doing so  
on the Yahoo! Toolbar, it gets reported as incompatible with FF3. The  
rogue extension then just has to call  
Components.classes["@mozilla.org/preference-service;1"].getService(Components.interfaces.nsIPrefBranch).setBoolPref("extensions.checkCompatibility",  
0).
Solution : check the integrity of signed extensions at startup. More  
generally, we can see no legitimate extension that would need to  
modify the files of other extensions.

2. The installation of an addon by an external program is not  
controlled properly, meaning that Firefox can get infected without  
user interaction.
To reproduce it : if you drop an XPI file in the extensions folder,  
FF3 issues a warning asking the user if he/she wants to install the  
extension. If the answer is no, the file is deleted. We think this is  
the expected behavior. However if we drop directly an extension  
directory in the extensions folder (we basically just unzip the XPI  
file) or if we drop a text file called whatever@malicious.org  
containing the name of the directory of the extension, FF3 issues a  
warning "a new component has been installed". Therefore the code gets  
executed without user consent. It might be possible to totally bypass  
the warning by setting up the environment correctly, so that the  
extension looks like it was already installed to FF.
Solution : ask the user if the extension has to be installed,  
regardless of its type/location.

3. An addon can disappear from the list of the installed extensions.  
Therefore the user loses control over what is installed in Firefox or  
not, combined with the problem above, this allows powerful hiding  
techniques for malware.
To reproduce it : there are several ways to hide the extensions from  
the addons manager. Mike Ter Louw [2] uses the interface  
nsIRDFDataSource. We implemented this behavior by using an XPCOM  
object to acces the file system and then to modify extensions.rdf,  
which explicitly 'contains non-startup and compatibility metadata for  
extensions that are visible to the user' [3].
Solution : there should be no ways for an extension to hide itself,  
since it is a feature that every malware wants to implement. Therefore  
there should be no list of extensions "visible to the user", and the  
objects allowing the extension to hide itself should at least be  
read-only.

4. Extensions can prevent being uninstalled from the addons manager.  
Once again, the user loses control over what is installed in Firefox,  
and this is definitely an interesting feature for malware writers.
To reproduce it : try to uninstall a rogue extension from the addon  
manager, it is now flagged as to be uninstalled after a FF restart.  
Then call  
Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.interfaces.nsIExtensionsManager).cancelUninstallItem(ROGUE_ID).
Solution : extensions should not be able to tamper with the addon  
manager (either the addon manager should not be available as an XPCOM  
object, or a policy should restrict access to it).


IMPACT

All these problems combined (and probably others that we didn't test  
or didn't think of yet) can lead to stealthy malware that infect the  
Firefox code base. It can then perform powerful payloads thanks to  
interfaces exposed through XPCOM objects : DOM manipulation (this is  
traditionally in banking malware for IE, click fraud and other  
adware), read/write access to the file system, network access via  
server and client sockets, access to the Firefox configuration,  
process launching, cleartext access to passwords stored by FF... Add  
this to the security feeling that users have about Firefox and the  
fact that extensions look innocuous but run at full trust once  
installed. We believe all this to be really appealing for malware  
authors because of the increasing market share of Firefox, and it  
becomes possible to write cross-platform malware in a high-level  
language. Also, as is the case with ActiveX controls and BHO objects  
in IE, malicious activity is indistinguishable from Firefox's  
activity, allowing to bypass personal firewalls and to mislead  
antivirus products.


FURTHER DISCUSSION

Another drawback of the current extensions model is the absence of any  
security model underlying their management. Once installed, an  
extension is fully trusted and can do whatever Firefox can do. Minimal  
security policies could probably be easily implemented, for instance,  
by default write access should be limited to the extension's  
directory: extended access to the entire filesystem should be granted  
only by an explicit user interaction. Also, new extensions should not  
be able to tamper with the extensions manager (without explicit  
rights). So we believe there is a need for a granular security model  
(à la Java or .NET).

Let us know what you think about all this, we would be more than happy  
to help you improve the security model of extensions in Firefox.

Best regards,
Daniel Reynaud and Philippe Beaucamps
PhD Students - Loria - Nancy - France



REFERENCES

[1] Loria's computer security lab : http://lhs.loria.fr
[2] http://www.mike.tl/view/Research/ExtensibleWebBrowserSecurity
[3] http://developer.mozilla.org/en/docs/Enhanced_Extension_Installation
Sounds like bug 219180 and/or bug 262762.
Just so I understand - all these attack vectors require either:

a) Local system access
b) Installing a bad extension?

The only thing concerning here is that removing a bad extension can leave traces in otherwise good extensions.   However, same is true of core Firefox code.   
(In reply to comment #0)
> 1. The integrity of signed extensions is not checked after  
> installation. ...

This is something that has been brought up before. It isn't impossible however some extensions do modify their own files after install (storing settings and cached content etc.), oddly the post even suggests that extensions be restricted to only writing to their own directory.

Also assuming some outside process has modified the extension it would probably be trivial for it to also change the list of which extensions are signed to stop us checking it.

> 2. The installation of an addon by an external program is not  
> controlled properly, meaning that Firefox can get infected without  
> user interaction.

This is somewhat intentional, allowing third party applications such as Skype to add their integration to the browser with minimal fuss. We do now tell the user that something has been installed but don't yet give them the chance to stop the install. Again with sufficient access to the filesystem already the list of known installed extensions can just be changed to get around whatever measures we put in place.

Note that the blocklist is checked before such add-ons are installed as a matter of course.

What isn't noted is that you don't need the extension manager to "infect" Firefox in this way. Assuming you have write access to the install directory you can just add stuff to the chrome and components directory to add code that can't be seen or uninstalled through the extension manager. Malware has used this mechanism in the past.

> 3. An addon can disappear from the list of the installed extensions.  
> Therefore the user loses control over what is installed in Firefox or  
> not, combined with the problem above, this allows powerful hiding  
> techniques for malware.

This is a known problem and I have some plans for solving the majority of cases here for Firefox 4. Note though that since extensions can overlay and change any UI they please then pretty much whatever we do to keep the list in the Add-ons Manager correct, an extension can just overlay the window and hide itself that way.

> 4. Extensions can prevent being uninstalled from the addons manager.  

This is a result of extensions having full access to the system.

> IMPACT
> 
> All these problems combined (and probably others that we didn't test  
> or didn't think of yet) can lead to stealthy malware that infect the  
> Firefox code base. It can then perform powerful payloads thanks to  
> interfaces exposed through XPCOM objects : DOM manipulation (this is  
> traditionally in banking malware for IE, click fraud and other  
> adware), read/write access to the file system, network access via  
> server and client sockets, access to the Firefox configuration,  
> process launching, cleartext access to passwords stored by FF... Add  
> this to the security feeling that users have about Firefox and the  
> fact that extensions look innocuous but run at full trust once  
> installed. We believe all this to be really appealing for malware  
> authors because of the increasing market share of Firefox, and it  
> becomes possible to write cross-platform malware in a high-level  
> language. Also, as is the case with ActiveX controls and BHO objects  
> in IE, malicious activity is indistinguishable from Firefox's  
> activity, allowing to bypass personal firewalls and to mislead  
> antivirus products.

I believe that the problem is that the extensions platform is great precisely because we let extensions get at everything. I have been thinking over the idea of slimline add-ons that have very limited UI and access to the system, but while that could work for maybe 85-90% of add-ons, it wouldn't be useful for the majority of the most popular add-ons.

(In reply to comment #2)
> Just so I understand - all these attack vectors require either:
> 
> a) Local system access
> b) Installing a bad extension?

I can't see any indication otherwise.
I think we should open up this bug: there's nothing here that hasn't been discussed in public already. And it should probably be marked INVALID, since it's too general to produce actionable results.
#1 makes it sound like Firefox checks the integrity of signed extensions on startup iff compatibility checking is enabled.  That could be a real bug, but not a security hole.

Other than that, this bug report is too general, and mostly covered by existing bug reports.
Group: security
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Product: Firefox → Toolkit
FYI, two of the security researchers are unhappy that this bug is marked INVALID, so they just blogged about it: 

In French: http://jp.gaulier.info/blog/index.php?post/2008/08/22/Firefox-ou-le-MSIE-du-futur (Headline: "Firefox, the MSIE of the future")

In English: http://indefinitestudies.wordpress.com/2008/08/20/malicious-firefox-extensions-continued/

See also http://lhs.loria.fr/?p=33 (older, but on the same topic).
> 1. The integrity of signed extensions is not checked after  
> installation.

My suggestion was to check the integrity of the code of the extension, not its settings. This is a security mechanism inspired by Java MIDlets: if the code is signed it can't be tampered with, but you can always write to a special directory where you can store settings, game saves in the case of MIDlets and so on.


(In reply to comment #3)
> Also assuming some outside process has modified the extension it would probably
> be trivial for it to also change the list of which extensions are signed to
> stop us checking it.

That's true. This protection would only work against rogue extensions infecting other extensions (assuming these rogue extensions are prevented access to the signed extensions list).


> > 2. The installation of an addon by an external program is not  
> > controlled properly, meaning that Firefox can get infected without  
> > user interaction.
> 
> ... Again with sufficient access to the filesystem already the
> list of known installed extensions can just be changed to get around whatever
> measures we put in place.

Agreed.


> (In reply to comment #2)
> > Just so I understand - all these attack vectors require either:
> > 
> > a) Local system access
> > b) Installing a bad extension?

Yes.

Fundamentally not much can be done against attacks coming from other processes.

However, I think that a sound extension management system should restrict what happens when a bad extension is installed (since bad extensions can also show up on AMO).
You need to log in before you can comment on or make changes to this bug.