security question - can add-on steal data from another?

<<

adamjakab

Posts: 17

Joined: Thu Dec 15, 2011 1:15 am

Location: Italy

Post Fri Dec 16, 2011 12:57 am

security question - can add-on steal data from another?

Hi,

I am building a password management add-on called Paranoia :ugeek: which uses private server(s) to store passcards (username+password+url+other) crypted with AES. As far as storage and server-2-client communication goes I think this add-on does a very good job.
Since it is the first time I develop an add-on for firefox and I don't have insights about what happens when add-ons get initialized and how they are "realated" to one another and my concern is:
once data is downloaded from servers, decrypted and stored in an array of custom classes inside a jsm module, is there even a remote possibility that another add-on can steal data from my add-on?

Can someone tell me if I can sleep soundly at night?
thanks
<<

archaeopteryx

AMO Editor

Posts: 1036

Joined: Fri Sep 25, 2009 1:38 pm

Location: Dresden, Germany

Post Fri Dec 16, 2011 4:32 am

Re: security question - can add-on steal data from another?

Add-ons have full user level access to the file system, so they can also access your addon's data.
<<

daniel-dawson

Posts: 138

Joined: Wed Feb 03, 2010 8:15 am

Post Fri Dec 16, 2011 5:18 am

Re: security question - can add-on steal data from another?

It's difficult, if not impossible, to keep add-ons from accessing each other's data. A JS module doesn't necessarily help, since they're designed for sharing data between different scopes; all another add-on has to do is import your module and call it in the same way your chrome does and it can get whatever data the API functions return. Of course, if the module never gives out passwords in any functions or methods accessible outside the module, that might be a different story (although, would it be a useful if it didn't do so?), as modules can control what data is accessible from outside, but I wouldn't rule out the possibility of being able to somehow get at the supposedly private data anyway.
<<

iann

Posts: 857

Joined: Thu Sep 16, 2010 12:56 pm

Post Fri Dec 16, 2011 5:24 am

Re: security question - can add-on steal data from another?

The possibility isn't remote. It is quite real and really quite simple. Your addon is part of the browser application and can be accessed in almost every way from any other extension. For example, they can call your functions just by knowing the name of them. Any preferences can be accessed just by knowing the name, passwords (stored in Firefox) can be accessed providing the user provides a master password, or if there is no master password configured. Any database or system file accessible to your extension will be accessible to any other extension that knows the filename and schema.

In order to provide security from other parts of the browser, you would typically place sensitive code into a dll which would make it more difficult to view and just slightly more difficult to access from other extensions, but it would be unwise to assume that anything you extension does can't be done by another extension.

Firefox provides security against web-based attacks and attacks from outside the application. It is assumed pretty much as given that any user should be allowed all access to the contents of their own profile, occasionally subject to knowing a password.
<<

adamjakab

Posts: 17

Joined: Thu Dec 15, 2011 1:15 am

Location: Italy

Post Fri Dec 16, 2011 8:57 am

Re: security question - can add-on steal data from another?

@archaeopteryx: I am not worried about access to files of my add-on on the file system and i am not even worried about accessing my preferences directly from prefs.js or through nsIPrefService because my add-on stores all preferences (server urls, login/password to access service, etc) crypted with AES

I am really worried about what @daniel-dawson and @iann are saying!!! :o
It's difficult, if not impossible, to keep add-ons from accessing each other's data...
and
The possibility isn't remote. It is quite real and really quite simple.
:o :o :o

This is quite worrying! I suppose I could (with lots of difficulty) restructure the add-on so that all sensitive data remains inside the module itself with private variables and private functions but what do you mean by this?
...as modules can control what data is accessible from outside, but I wouldn't rule out the possibility of being able to somehow get at the supposedly private data anyway...

Then again, i was thinking, even if all add-ons would be completely isolated, once my pwd manager fills in the form with the login info, both username and passwords in clear text would be available to all addons anyways - it would be enough to listen to posts or input filed changes, no?

But still, wouldn't it be better if add-ons were isolated? Would it be difficult to do?

... ;) now you ruined my sleep...
<<

iann

Posts: 857

Joined: Thu Sep 16, 2010 12:56 pm

Post Fri Dec 16, 2011 9:23 am

Re: security question - can add-on steal data from another?

Private contents of a javascript code module are not visible by default, in the same way that local variables in a javascript function are not visible from outside, but that doesn't mean that they can't be detected by javascript with sufficient privileges. Essentially the entire javascript codebase could be rewritten by a malicious extension, and certainly by a user who cared to do so, so you shouldn't be storing anything truly valuable in there.
<<

daniel-dawson

Posts: 138

Joined: Wed Feb 03, 2010 8:15 am

Post Fri Dec 16, 2011 10:08 am

Re: security question - can add-on steal data from another?

adamjakab wrote:@archaeopteryx: I am not worried about access to files of my add-on on the file system and i am not even worried about accessing my preferences directly from prefs.js or through nsIPrefService because my add-on stores all preferences (server urls, login/password to access service, etc) crypted with AES
I assume the encryption key is derived from some sort of user-provided password.

This is quite worrying! I suppose I could (with lots of difficulty) restructure the add-on so that all sensitive data remains inside the module itself with private variables and private functions but what do you mean by this?
...as modules can control what data is accessible from outside, but I wouldn't rule out the possibility of being able to somehow get at the supposedly private data anyway...
I mean, if it can be done, I have no idea how. But I wouldn't trust the fact that there is no obvious way to do so. AFAIK, the access control is more for modularity than security, in the same sense that some programming languages have public, private, etc., access for certain things, so developers are discouraged from messing around with things they shouldn't according to best practices (and they might also facilitate certain compiler optimizations). The symbols exported by a module are imported directly into whatever scope the module is imported in, and you want to minimize namespace pollution in some places, like the main browser window object, while still having plenty of coding freedom within the module.

Then again, i was thinking, even if all add-ons would be completely isolated, once my pwd manager fills in the form with the login info, both username and passwords in clear text would be available to all addons anyways - it would be enough to listen to posts or input filed changes, no?
Very true.

The fact is, there isn't really a security model among add-ons.

But still, wouldn't it be better if add-ons were isolated? Would it be difficult to do?
Perhaps. But the Mozilla philosophy seems to be that a developer should be able to freely modify pretty much any browser behavior. Trying to separate add-ons might impede that freedom. (Well, I might be off in my assessment here, but they do have reasons.) The lack of security here is one of the major reasons AMO has a human review policy, so it's harder to put malicious code (including the kind of thing we're talking about here) into add-ons. It's certainly not perfect, but it probably does a pretty good job.

If you want to better hide sensitive data, making a binary component as iann suggests is worth looking into. The downsides, of course, are that you have to write in C++ and have to be more careful and disciplined than when writing in JS (a mistake might cause a crash, for instance), and you have to compile it for every platform you want to support unlike with JS.
<<

adamjakab

Posts: 17

Joined: Thu Dec 15, 2011 1:15 am

Location: Italy

Post Sat Dec 17, 2011 4:21 am

Re: security question - can add-on steal data from another?

iann wrote:...Essentially the entire javascript codebase could be rewritten by a malicious extension, and certainly by a user who cared to do so, so you shouldn't be storing anything truly valuable in there.

Fair enough, but are we talking about add-ons that were downloaded and installed from mozilla add-ons site, and hence they passed full revision process? Do you think something like this could/would pass unobserved? Has anything like this ever happened in the past?

daiel-dawson wrote:...the Mozilla philosophy seems to be that a developer should be able to freely modify pretty much any browser behavior...

OK, let's take it for granted that there is no isolation whatsoever between add-ons and probably there will neve be. Even though, whilst I do agree that add-ons should be able to freely modify browser behaviour as far as the core application goes, add-ons are third-party software, should be considered as such, and I don't think they should be able to interact with one another - at least not if the add-on does not specificly allow it.

I did not resist, and I created an add-on to test access to my ParanoiaPasswordManager(PPM) variables and functions.
My PPM has a component (wrappedJSObject) created with the aid of XPCOMUtils and all it does really is to import my main module called main JSM and spins off the init process. Main.jsm exports (var EXPORTED_SYMBOLS = ["ParanoiaPasswordManager"];) in the global namespace and the other four jsm modules are imported in the ParanoiaPasswordManager scope: Cui("resource://paranoiaModules/configuration.jsm", ParanoiaPasswordManager);

so then I tried from my second add-on(i called it Datathief):
  Code:
var WIN = Cc["@mozilla.org/appshell/window-mediator;1"].getService(Ci.nsIWindowMediator).getMostRecentWindow("navigator:browser");
var PPM = WIN["ParanoiaPasswordManager"];
/*from here on I had access to all public variables and methods*/


This made me :cry: but after what you said previously I sort of expected it. In fact, I easily picked up the full array of passcards(my own class that holds) which have the public get/set functions (without which my add-on would be useless) and traced the to console. Then I killed PPM preferences and shut it down. With a couple lines of code I stole all sensitive data and PPM was not even able to log back in because all its preferences were removed.

And again, the fact that any add-on can do
  Code:
Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefService).getBranch("extensions.paranoia.").clearUserPref("settings");
Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefService).savePrefFile(null);

killing immediately preferences of any add-on I don't find a good idea. I know, add-ons are integral part of the application so they can do whatever the application does - but this paradigm is well dangerous.

Anyways, I came up with this and I'd like to know if you recon this can work somehow.
In my passcard.js which is a "class" instanced for each username/password pair i put this "private" method:
  Code:
var checkCallerStack = function() {
      var isAllowed = false;
      try {
         throw new Error("Ooops!");
      } catch(e) {
         if (e.stack) {
            var callstack = e.stack.split("\n");
            callstack.shift();//remove reference where "Ooops!" was thrown
            callstack.shift();//remove reference to method that called checkCallerStack
            var caller = callstack[0];//this is the reference that called our "souldBeProtected" method
            if (caller.match(/(@resource:\/\/paranoiamodules\/|@chrome:\/\/paranoia\/content\/)/)) {
               isAllowed = true;
            }
         }
      }
      return(isAllowed);
   }

and in my getter method i put:
  Code:
this.get = function(prop) {
   if(!checkCallerStack()){return(false);}
   /*...rest of stuff...*/
   return(val);
}


As e.stack actually does give a very simple stacktrace of functions, arguments, line numbers and file names when I call the checkCallerStack function from PPM the caller is identified as @resource://paranoiamodules/[some jsm] or @chrome://paranoia/content/[some xul or js] because it is defined in the add-on's chrome.manifest file in lines:
  Code:
content         paranoia               chrome/content/
resource      paranoiamodules      modules/


And with this, my Datathief add-on was refused to the get method because it was identified as caller: @resource://datathiefModules/utils.jsm
I also tried to change the modules alias of Datathief from
  Code:
resource      datathiefModules      modules/

to
  Code:
resource      paranoiamodules      modules/

so to mach PPM's module folder alias and so to fool the checkCallerStack method, and actually it does work, but I have in both add-ons main.jsm as the principal JSM fired up by the component so the first that get inizialized works the second one halts with error. If they had different names they would both work and be identified as @resource://paranoiamodules/[some jsm] so my function above should check the exact resource path to the jsm - since I have 5 it could be done.

So, do you recon this could work? Do you see any problems with this?
<<

daniel-dawson

Posts: 138

Joined: Wed Feb 03, 2010 8:15 am

Post Sat Dec 17, 2011 7:45 am

Re: security question - can add-on steal data from another?

adamjakab wrote:Fair enough, but are we talking about add-ons that were downloaded and installed from mozilla add-ons site, and hence they passed full revision process? Do you think something like this could/would pass unobserved? Has anything like this ever happened in the past?
Doubtful. AMO editors are supposed to review every line of code in an add-on for all sorts of problems including malicious code, and messing around with sensitive data that doesn't seem to be relevant to the add-on's purpose is a definite red flag, and there are policies in place to try to prevent developers hiding what their code does. It's also worth noting that if an add-on wants to modify another, it will either need to declare a dependency or check for that other's presence at runtime; both would be difficult to hide. Of course, editors are only human, so depending on how subtly it's done, it's at least theoretically possible.

OK, let's take it for granted that there is no isolation whatsoever between add-ons and probably there will neve be. Even though, whilst I do agree that add-ons should be able to freely modify browser behaviour as far as the core application goes, add-ons are third-party software, should be considered as such, and I don't think they should be able to interact with one another - at least not if the add-on does not specificly allow it.
I suppose can agree in principle. However, there is fundamentally no distinction. Any code an extension adds becomes an integral part of whatever scope it's added to. There are sometimes good reasons for being able to do things like replace functions. As an example, one of my add-ons adds a column to a table; the trouble is that everything is controlled by a dynamic implementation that isn't designed to be extended, so the only solution I could come up with was to replace functions with my own that handle the extra column.

Granted, that's with toolkit code, not another add-on, but it could easily be. Now, you might argue that it would be best just to write another add-on from scratch, but depending on the size and complexity of the existing add-on, as well as its licensing (in case one wants to reuse some of its code), that might not be very practical. In cases like this, it's quite useful to be able to modify things dynamically.

  Code:
var WIN = Cc["@mozilla.org/appshell/window-mediator;1"].getService(Ci.nsIWindowMediator).getMostRecentWindow("navigator:browser");
var PPM = WIN["ParanoiaPasswordManager"];
/*from here on I had access to all public variables and methods*/
That works, although as I said before, it's easy enough just to import the module directly with Cui(), since resource namespaces are accessible from any privileged code, not just the add-on in which they are installed. (Indeed, any name or namespace defined in a chrome manifest, such as content, locale, skin, component, interface, etc., is accessible from any privileged code; it's just that legitimate add-ons don't often use each other's stuff.)

And again, the fact that any add-on can do
  Code:
Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefService).getBranch("extensions.paranoia.").clearUserPref("settings");
Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefService).savePrefFile(null);

killing immediately preferences of any add-on I don't find a good idea. I know, add-ons are integral part of the application so they can do whatever the application does - but this paradigm is well dangerous.
A good use case is something that cleans up unwanted preferences left over from uninstalled add-ons, such as Preferences Cleaner. (The toolkit doesn't do this automatically, probably because of the possibility that a user would want to keep some preferences while temporarily uninstalling or disabling an add-on.) Of course, the difference here is it's done with explicit user consent. Any add-on that messes with preferences other than its own without user knowledge or consent is supposed to be denied full review.

So, do you recon this could work? Do you see any problems with this?
It looks like it might, but I didn't really examine it in any detail, and it's a bit beyond my expertise anyway.
<<

iann

Posts: 857

Joined: Thu Sep 16, 2010 12:56 pm

Post Sat Dec 17, 2011 2:16 pm

Re: security question - can add-on steal data from another?

I know, add-ons are integral part of the application so they can do whatever the application does - but this paradigm is well dangerous.


I'm afraid you've created your own paradigm and are now disappointed that Firefox doesn't adhere to it. You want your own personal bit of Firefox to somehow have privileges that no other part of the application has. Even allowing for the desire for private data within some sort of "class", which is not in itself entirely secure, Javascript simply isn't the language to do it in.
<<

adamjakab

Posts: 17

Joined: Thu Dec 15, 2011 1:15 am

Location: Italy

Post Mon Dec 19, 2011 9:10 am

Re: security question - can add-on steal data from another?

iann wrote:I'm afraid you've created your own paradigm and are now disappointed that Firefox doesn't adhere to it. You want your own personal bit of Firefox to somehow have privileges that no other part of the application has. Even allowing for the desire for private data within some sort of "class", which is not in itself entirely secure, Javascript simply isn't the language to do it in.


Well, yes and no.

Yes, I am a bit disappointed. Don't take me wrong, I think that the development team, the AMO editors and you guys moderating this forum are doing an excellent job and I want to voice my appreciation for the time and effort all of you all put into this project.

I guess, my disappointment is fruit of my ignorance that has now partly vanished. The realization that FF is not as I imagined to be is a cold shower.

You can tell by the original title of this post that I did NOT have a clue about relationships between addon-2-addon and core_application-2-addon. When I asked:
me wrote:...is there even a remote possibility that another add-on can steal data from my add-on?

I expected someone saying:
nobody wrote:No, you don't have to worry about that!

I tried and as you say "it is really quite simple". I really did not expect this.
I also know that JS has its limits and, under the current circumstances, I agree with you that it is not the right choice for my add-on to hold sensitive data.

But even if it wasn't the case, my original preoccupation has become secondary. The real problem is another. Once the username and the password make it to the form they are completely at the add-on's mercy. Even if they came from a secure channel, encrypted, and stored in some super-secure dll once they become clear text values in form fields, they are free to be accessed by any add-on. Which would not be a problem as long as add-ons could be controlled where to send out data to.

Talking to you guys made me do some reading on-line about FF security and I came upon this. You might remember the Security Vulnerability Announcement written by Jorge Villabos on 13/07/2010 about the MozillaSniffer issue:
Jorge Villabos wrote:If a user installs this add-on and submits a login form with a password field, all form data will be submitted to a remote location...

**zzo!!!! Well, Sniffer it is called and that's what it does...

You see, this one has slipped through full review. I repeat, I think AMO editors are doing a great job and maybe one day when I have the competence I will ask to join them to help. But we must know our limits - WE ARE HUMANS AND WE MAKE MISTAKES.

As a matter of fact, on the same bulletin there is another issue: CoolPreviews. A little "funky" code in the href attribute that you don't even have to click(just hover) and it would attempt to make changes to your OS's hosts file. I am really happy for those !!! 177.000 users !!! that this one was a proof of concept and maybe only 10% of them had their names written into their hosts file. It is still 17.000 users who risked big time! You know, I am a *NIX user and I use superuser for what it is intended to be used for - but talk to the "normal" Windows users. From my experience 1 out of 2 uses admin privileges for every day tasks (such as browsing on the web) because doing so they can do things without being asked "stupid" questions by OS.
Now, can you tell me why on earth FF, or any other application intended to browse remote resources (rating from secure to evil), should have access to the hosts file, or for that matter to any file outside of the users home folder(one could even argue outside the current profile)??? For me, there can not be a plausible answer to this.
In fact, I would really like to know what actions were taken, apart from obviously removing the add-ons, to make sure threats like this never repeated again.

... and the no part...

No, this is not my paradigm. Perhaps I use the term inappropriately. What I mean is "by definition". By definition, my add-on, as any other, is integral part of the core application and as such have as much "power" as the core application itself. This is not something I required or set when I created my add-on. FF gives me all this "power" without any further ado. You say:
iann wrote:...you want your own personal bit of Firefox to somehow have privileges that no other part of the application has

but I don't really. I don't wan't access to system files, I don't want launch separate processes, I don't want to modify/erase preferences of the core application or of other add-ons and I don't want to access other add-on's methods or variables. I don't need any of this stuff. But my add-on is granted to do all of it. The only thing I want is the privacy of my add-on but this one I cannot have.
Well, yes I can, but the only way to do that is by being the ONLY add-on installed in that profile.
And this is quite a disappointing conclusion.
<<

jorge-villalobos

AMO Administrator

Posts: 3005

Joined: Tue Sep 29, 2009 7:30 pm

Location: San José, Costa Rica

Post Mon Dec 19, 2011 9:42 am

Re: security question - can add-on steal data from another?

Wow, long thread. I just want to address the issue with the security disclosure that was quoted above. From the same post:
Mozilla Sniffer was not developed by Mozilla, and it was not reviewed by Mozilla.

This was from a time where we had a sandbox model with 2 levels: sandbox and public. Add-ons in the sandbox were still publicly visible and could be downloaded with a warning. This was not a very good security model for AMO, so we switched to a different one. All add-ons that you can now find on AMO have been reviewed, at least on a security level, so they should be safe to use. However, we do make mistakes, and it is possible for unsafe add-on versions to go through. We do our best to avoid these situations, but there are cases where we just can't help it.
There's little I can add to the discussion. Like others have said, add-ons running in the same session are not protected from each other and can do anything. There are ways to protect your operations somewhat reasonably, like private code running in a JSM or a binary component. It's still possible to tap into the JS that calls these modules and redirect it elsewhere, but that requires some effort to replicate all of the functionality in those modules, assuming that the malicious add-on wants to go unnoticed. This kind of interference would most certainly be noticed by editors and wouldn't pass review on AMO.
<<

adamjakab

Posts: 17

Joined: Thu Dec 15, 2011 1:15 am

Location: Italy

Post Tue Dec 20, 2011 12:21 am

Re: security question - can add-on steal data from another?

Thanks Jorge,

Yes this was a long thread but I guess you quite well understood the what I was aiming at to get out of this conversation. And as you say:
jorge-villabos wrote:...However, we do make mistakes, and it is possible for unsafe add-on versions to go through. We do our best to avoid these situations, but there are cases where we just can't help it...

You know, when I was 8 I was already coding on my C64. Since then lots of water has gone down the rivers and one very important thing I have learned is that if you are a developer you must know about the security of the environment you are developing in - and what you are saying up here should be very clear to all who develop add-ons for FF. :D It was much simpler on the C64...

Having said that, don't you recon this current way of considering 3rd party add-ons as integral part of the core application could/should change in the future?
<<

jorge-villalobos

AMO Administrator

Posts: 3005

Joined: Tue Sep 29, 2009 7:30 pm

Location: San José, Costa Rica

Post Tue Dec 20, 2011 3:33 pm

Re: security question - can add-on steal data from another?

The current approach gives developers great freedom, and it allows them to create really complex and unexpected experiences. Sandboxed models such as the ones provided by Chrome and most mobile app systems are very secure, but limit all creativity to what the API designers allow. I find that too restrictive. FWIW, the new Add-ons SDK is using a similar approach, where the default expectation for these add-ons is to run in a sandbox and use vetted APIs. It may be harder (but probably not impossible) for traditional extensions to tap into that code. You might want to look into that.

Return to XPCOM, Plugins and Binary

Who is online

Users browsing this forum: No registered users

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
CA Gen2 style designed by Vjacheslav Trushkin.