Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I recently learned about a plugin for Firefox called Fire Sheep, which was featured on the Security Now podcast. I downloaded F.S. and began examining it. To my surprise it includes C++ code that must be compiled for the plugin to work.

My impression had always been that Firefox, unlike IE, does not allow execution of downloaded object code within the browser. F.S. seems to contradict this.

What are the security implications of people downloading plugins, thinking that they are safe, when they could easily contain malware in the form of Trojan object code or even Javascript exploits?

share|improve this question
On a side note this is how I got spyware on a Linux machine. –  rook Jul 1 '12 at 20:53
This is asking for add-on "add-on validator", which is add-on checking new add-ons for the malware and reputation. –  Andrew Smith Aug 4 '12 at 11:32
@Rook: can you please elaborate on how you got spyware? –  Martin Vegter Dec 14 '13 at 17:25
@Martin Vegter downloading a firefox addon that wasn't from addons.mozilla.org –  rook Dec 14 '13 at 17:48
@Rook: does it mean that Addons from addons.mozilla.org can be considered safe, especially when they are in the form of source code (not compiled) ? –  Martin Vegter Dec 14 '13 at 17:59

6 Answers 6

If people do not read the big fat warning that is displayed on every installation of a Addon or Plugin by Firefox, they have lost. Addons are full programs that can do anything, you have permission to do.

The warning message is really obvious:

You should only install add-ons from sources you trust.

Evil software can harm files on your computer or violate your privacy.


share|improve this answer
You are kind of right - alas, I happen to be plagued by big scary warning messages, everywhere: "OMG self-signed HTTPS certificate, EVERYONE PANIC!!1!" "YOU HAVE CLICKED THE LEFT MOUSE BUTTON, THIS COULD BE DANGEROUS, ARE YOU SURE!!!?" "THREE UAC PROMPTS IN A ROW, ARE YOU REALLY REALLY REALLY SURE?!?!one!" and the like. I'm aware of the meaning of such messages, but an average user will quickly learn that "nothing bad happens" - and they're right, until something does happen, as one of the warnings was actually relevant. I don't see any Good Solution (sealed systems have their own problems). –  Piskvor Aug 4 '11 at 13:31
I wouldn't call it obvious. It's vague to the point of uselessness. –  CodesInChaos Jul 3 '12 at 15:22
@Piskvor Yeah, those UAE prompts totally train users to ignore them. Where's the "I trust this particular program; don't warn me again unless it changes" button?... –  romkyns Mar 18 '13 at 16:58
if users followed the prompt literally, they would never install any add-ons whatsoever, for the very simple reason that you cannot - it would be rather irresponsible - actually fully trust people (=developers) that you do not personally know. But that would make FF's add-on architecture a stupid idea to begin with. So rather than fixing their browsers architecture, FF places the responsibility on the user to "assume" a level of trust and therefore the responsibilities with it. –  coderworks Aug 22 at 3:43

The terminology a particular browser uses to describe addons is slightly unhelpful. Some browsers call some things addons, some browsers call some things extensions. Somebody at some point came up with the idea of naming temporary storage "cookies" after all and how useful is that as a name.

So an extension mechanism (as in any extension to the browser's functionality) works on two levels:

1) The browser implements some sub language like XML-rendered user interfaces (XUL in firefox is this, specifically xulrunner allows you to describe a user interface in xml). Also, much of firefox extensions can be implemented in javascript (look up spidermonkey and the like, this is a component of firefox that executes javascript - in firefox, there are additional functions that allow that javascript to do things, like transform the DOM of the currently browsed page, or whatever. At this level the browser can control what the extension does fairly trivially, but anything the extension wants to do that firefox does not support or won't allow, cannot be done. Here's a picture:

  OS <--  Firefox <-- Nice extension interpreter <- extension javascript.

2) Sometimes, you need to do something firefox isn't built to do, or cannot efficiently be done in a javascript-or-other-interpreted format, like execute flash or decode weird-codec.oddfile, for example. Situations like this firefox tends to handle with "handlers" which operate a bit like this:

  OS <--- Firefox  <--- webpage containing something
          Plugin API---Relevant part of webpage, like <embed>
              |                 |
  OS <----- Plugin! like ns_flash.so or such like

Here, extensions are compiled to match firefox's extension architecture for this sort of thing. Firefox exposes a certain set of functions to allow the extension to control it in certain ways, but the extension can also ask the operating system to do things directly. If it is well behaved, it basically takes the relevant input (i.e. here's a .swf file) and does whatever it needs to do ("firefox, in this box, please draw this video"). However, it could technically do anything your user can do, because firefox isn't stopping it.

As to why Firesheep must be compiled, this is because it depends on libpcap (or similar), which is about extracting information packets from "the wire" i.e. from a device that's receiving them. A wireless interface is particularly susceptible to this because many wireless adapters are omni-directional so any interface in the vicinity picks these packets up. Usually, your kernel (operating system) would drop packets not addressed to it, however, setting the interface to promiscuous mode is how you ask it not to. libpcap does this for you and allows you to grab those packets. In order to do this, it needs direct (probably administrative/root) access to the OS.

Firesheep works entirely by analysing those packets, finding http ones that aren't encrypted, scraping them for login data then reporting it.

Now, back to the security risk from these plugins - it's fairly obvious, a plugin that works as native code (in firefox, a plugin, rather than an extension) can do whatever you the user can do (forget firefox)) so as Hendrik rightly puts it, if you ignore the big fat warning, that's a problem. An extension ought to be able to do limited damage.

Whilst we're here, the google chrome model is different again. Every application on a computer is comprised of processes and threads - in many oses threads are basically lightweight processes and share memory across the process and that is how you achieve concurrency, however, a single crashed thread brings down the entire process and any thread can technically alter the memory of another thread without restriction.

So google chrome works by creating processes for every unique domain you visit uniquely, acting as if you had a process per tab (for many use cases) and every running extension you use. Actually, you can also customise this to execute a process per tab, or just one process per domain regardless of the visits you make. So whereas in firefox you get:

 Firefox   thread/1

In google chrome you get

 Chrome master process

                Chrome child process for security.stackexchange.com
                Chrome child process for meta.stackoverflow.com
                Chrome child process for flash

Now, each child process is heavily restricted. The standard way to create a process gives it by default whatever permissions the parent has (inheritence) but google chrome sets permissions explicitly. Child processes can only communicate with the parent process when they want to do something and any API calls they make to the OS are severely restricted by windows' own access control tokens. So the idea here is that a plugin ought, in theory, to only be able to do what it needs to.

That is very much the theory of google chrome's idea. In practise the design documents imply you have to pass --sandbox-plugins i.e. I'm not currently sure to what extent sandboxing plugins is automatic and whether they all work correctly yet.

share|improve this answer
This is pretty good, but there are some small inaccuracies. In Firefox, extensions can run native code (shell commands). Most Firefox extensions don't exercise that power, but the extension system does give them the power to do so. –  D.W. Aug 4 '11 at 4:23
Excellent technical breakdown! Though notably IE is missing... possibly because it's even more complex than Chrome. In recent versions (I believe from IE7, but it may have been only since IE8...), IE uses a similar model to Chrome - but with a further segregation, based on Windows Job processes. This actually allows IE to cleanly isolate different sets of processes, e.g. if opened in a different window (not really so simple, different cmd-line args can change this...). So you in effect have several "master processes", and each set of master/child processes are isolated from the others. –  AviD Aug 7 '11 at 15:02
AviD - thanks. I've not looked at recent IE models, but it doesn't sound too far away from Chrome, i.e. if the Chrome "shell" (UI) were a separate process for each Window, it would essentially be the same thing. D.W. - I didn't know that... although it makes sense, that must be how GPG/Thunderbird communicate via the gpg extension. I'll edit that in. –  user2213 Aug 7 '11 at 16:25

Firstly, you are missing the distinction between "add-ons" (or "extensions") and "plugins". "Add-ons" modify the browser's functionality in some way, usually making life easier. For this reason, they have a lot more control, and lesser access restrictions than "plugins". They are also (usually) cross-platform. "Plugins" are platform-dependent modules that allow a browser to display content it would not otherwise know how to display, like PDF files, or videos.

Add-on security depends on the browser implementation. Firefox, for example, gives add-ons a lot more access than Chrome does to its extensions. Plugins have the same access across browsers. Some plugins, like Flash, request files through the browser, subjecting them to restrictions that browsers (or add-ons) may impose. For example, RequestPolicy, and add-on that controls cross-domain requests in Firefox, can (and does) block cross-domain requests in Flash content. Java, on the other hand, can run code in the JVM independently of the browser.

I don't know for sure, but I believe the reason FireSheep includes C++ code is because it needs to capture all packets flowing on the network, which is something Firefox does not allow. In order for FireSheep to do so, it must run some manner of native code.

As for other add-ons, in Firefox, a malicious add-on has access to all your history, your saved passwords, bookmarks, and can modify the look and feel, and behavior, of any web page it desires. In Chrome, though, it must explicitly declare its desired access, and Chrome will inform the user what the extension needs access to before installing it.

A plugin is almost comparable to native code, so a malicious plugin has access to whatever the operating system gives it access to. If you download and install a malicious plugin, its the same as downloading and installing any other malicious program.

share|improve this answer
In Firefox an addon does not only have access to browser stuff but can execute any program and has access to the hard disk, too. It can mess with your personal files, modify them, transmit them to the internet, etc. –  Hendrik Brummermann Aug 3 '11 at 6:17
Actually, this answer uses and defines the standard terminology incorrectly. Firefox uses the term "add-on" as a general category that includes both extensions and plugins. Extensions are one kind of add-on, but not the only kind. –  D.W. Aug 11 '11 at 3:41

Only run trusted software on your computer. http://technet.microsoft.com/en-us/library/cc722487.aspx

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore

I'm confused about your description of Firesheep needing to be compiled before working; please could you expand that? Also, strictly, firesheep is a firefox extension not a plugin.

share|improve this answer
This Law sounds good, but it's not really totally accurate. Example: A bad guy may be able to get your browser to run Javascript (by embedding it in his web site and getting you to visit his web site), but that usually doesn't allow him to own your computer. Example: If you use Chrome and you install an extension from a bad guy and the extension doesn't have critical permissions, then the damage the bad guy can do is limited: in particular, it is still your computer, and the bad guy can't own it. –  D.W. Aug 11 '11 at 3:43
Yes, the laws are old and could do with a bit of updating. They're also aimed at a general audience, not specialists. With that in mind it's good advice: "Be careful what you run on you computer." Also, while the bad guy can't own the box there have been several malicious javascript exploits that allowed arbitrary code execution. Your point about the good security of Chrome is taken. –  DanBeale Aug 12 '11 at 7:25

You are confusing web page elements and browser plug ins.

Many web pages contain code (usually written in JavaScript) that run in your browser, but in a carefully fenced off area (conceptually, a sandbox — not necessarily a sandbox in any particular technical sense). The code contained in a web page has no access to anything other than its own data; in particular it can't access the data of web pages from other sites, or data elsewhere on your computer, or execute code that has any impact outside the browser. (Unless there's a bug in the browser, of course.)

Browser plug-ins and extensions are applications that run on your computer. Unlike “full” applications like the browser itself, plug-ins and extensions do not run natively on your operating system: they only operate as additional components of your browser. There is no a priori expectation that these applications have restricted permissions.

There is no fundamental difference between plug-ins and extensions; they simply use different interfaces to communicate with the browser. Plug-ins run native code directly, so they can do anything that the operating system allows to applications you're running. Extensions are tamer; Chrome extensions do have a permission system, and other browsers also put restrictions on what extensions can do. Nonetheless, extensions have enough permissions that a mischievious extension can cause harm. You must exercise as much caution when installing a plug-in or add-on as when installing any other application on your computer.

share|improve this answer
"There is no fundamental difference between plug-ins and extensions; they simply use different interfaces to communicate with the browser." - That might be a little misleading. In some browsers (e.g., Google Chrome), there is a fundamental difference between plug-ins and extensions: plug-ins always have all the powers of native code, whereas most extensions do not. In Chrome, most extensions are significantly less risky than installing a plug-in or installing a desktop application. In other browsers (e.g., Firefox), there is no significant difference in the permissions they receive. –  D.W. Aug 4 '11 at 4:21

Some browsers do chroot jailing, syscall interception, and the like to sandbox extensions as defense in depth against zero-days in flash and the like, but a lot of browser extension mechanisms grant a lot of authority to extensions.

Native Client is an attempt to provide an in-browser sandbox for native compiled code and could form the basis of a new more flexible mechanism for sandboxing native extensions.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.