Browser Plugin Security?
A friend of mine raised a valid concern about password managers in general, and I wonder how AbileBits has protected 1Password against this attack vector. I tried to do some googling but didn't find any explanation - feel free to point me to a eg. blog post if I missed one. Also, please point out fallacies in my reasoning.
The 1Password browser plugin lives in an hostile environment. Depending on the browser architecture it is possible to craft a web page containing a program that manages to subvert the browser to give the program access to the 1Password plugin. If this happens, it is possible that the plugin is then subverted to fetch the contents of the 1Password database.
The obvious safeguard is that this is not possible if the 1Password database is locked. But if it is unlocked, the plugin works transparently from the user, and the attack could go unnoticed.
Are there any other safeguards built in? An additional safeguard that comes to mind would be to have the Mini give a visual indication when a browser plugin fetches a data, and also a rate limit to the speed a plugin can query data.
Comments
-
Yesterday's AgileBits blog item touches on aspects of what you mention. You may find it interesting.
Stephen
0 -
I actually did read it already, but it does not really address the problem of subverting the plugin to provide the contents of the password database.
0 -
This is a really good question, @Killeri. Thank you for raising it.
There are several things we do to protect against this attack. First and foremost, the 1Password extension is NOT simply a piece of JavaScript or plugin running directly into the webpage itself. If it was, you're right, it would be very difficult to identify valid requests from malicious ones. Instead, by using the extension architecture provided to us by the browsers, 1Password's JavaScript code is able to run within its own isolated world. This isolation alone provides protection against a vast array of possible attack vectors.
One of the other benefits provided by the extension architecture is the origin of the request includes the bundle of the extension making the request. When we receive a request from Safari for example, we are provided an origin like
safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c. This bundle is unique to the 1Password extension, which allows us to prevent communication with other (potentially malicious) extensions.Another defensive measure we take is to verify the code signature of the connecting process. This allows use to ensure that only trusted and unmodified browsers are able to communicate with us.
As far as I know, none of these safeguards are available with an old fashioned plugin, which is one of the biggest reasons we don't use those.
I hope this helps answer your questions. Please let me know if you'd like me to elaborate on anything.
Cheers!
0 -
Hi Killeri,
You are correct that a fully compromised 1Password Browser extension could request secrets from an unlocked 1Password Mini/Helper. I didn't mean to suggest otherwise. If you read through the original paper, you will find that the attacks documented involved didn't actually involve complete compromises of the extensions. Instead the attacks exploited misfeatures/bugs of those extensions.
So the first, and most important, line of defense is to prevent the extension from compromise.
Extension sandboxing
Unlike bookmarklets, browser extensions are sandboxed by the browsers. Each browser has different ways of doing this, but
this prevents attacks from other extensions, activities in other tabs, etc.Reduced attack surface.
By making the browser extension "thin" there are fewer places for us to make errors in the extension itself.
We already use much of the defensive JavaScript techniques recommend in the paper.
JavaScript can be a very dangerous language. But, it can also be a very safe one if the developer follows a few habits. We have been using those safe habits for many years.
Attack may have to go deeper
Because of the "thinness" of our extension it is more likely that an attacker would need to completely compromise the extension instead of just exploiting bugs/misfeatures.
I realize that I've larger repeated what is in the blog post. I don't know whether that sufficiently addresses your concern. You can opt to run 1Password without installing the extension, but that exposes you to other risks, such as greater use of system clipboard, and phishing. As you see, many security choices are security/security tradeoffs.
The second line of defense is to have Mini/Helper try to detect suspicious behavior from the browser extensions. This isn't a very good line of defense because it involves some "security by obscurity" (in determining what is "suspicious behavior"). Because a lot of this is "obscure" and under development, I am going to remain vague. It also isn't a high priority of development because it could be evaded by a sophisticated attacker.
0 -
Thanks! One of the things I like about 1Password and AgileBits is that you guys are willing to explain the security approaches you have taken. And at the end of the day, like you said, there is no absolute security, the best you can do is make informed choices.
0
