Ubiquity Security Concerns Part 1: An Introduction

Introduction

I recently watched a short video about a Mozilla Labs project called Ubiquity. After watching this video, I became extremely excited about using the features presented and extremely scared of how the extension could be exploited to compromise personal data. I wanted to both benefit from this awesome and fun extension and also find ways to execute arbitrary JavaScript within others' browsers (the same feeling I get whenever I use Google). It may be helpful to briefly watch this video to understand this sentiment:

http://www.vimeo.com/1561578?pg=embed&sec=1561578

After watching this video, my first thoughts were:

1. I wonder if an attacker could write a command to send arbitrary GMail messages on the users' behalf, watch every page the users visit, steal passwords, and even compromise users' computers.

and

2. How difficult would it be for an attacker to trick a user into installing the command or cause the command to be installed in an automated fashion?

The short answer to 1. is YES (details provided below)! Answering 2., specifically the automated portion, will require some research.

Ubiquity Developers' Awareness of Security Concerns

Before anyone gets too worked up about these security issues, I should make sure it is clear that this project is far from being complete, the authors are well aware that there a significant security concerns, and they are in the process of determining a method to reduce the risk of malicious commands or other exploits.

Examples of this awareness can be found in Atul's blog entries:

Trusting Functionality and Towards Inter-Community Trust

"At present, because our project is still in the prototyping stage, we’re opting for freedom of expressiveness and experimentation over security. That means that all the various verbs we write, while written in JavaScript, are always executed with Chrome privileges, meaning that they’re capable of doing whatever they want to the end-user’s computer."

"So the particular dilemma that needs to be solved here is: how can an end-user trust that a verb won’t do anything harmful to their data or privacy—be it intentional or accidental—while still providing a low barrier of entry for aspiring authors to write and distribute their own verbs?"

More specific concerns can be found in the Ubiquity Author Tutorial.

Ubiquity_0.1_Author_Tutorial#Sharing_it_with_the_World

"If the user chooses to subscribe to a command from an untrusted source, they will get a security warning message before they can install the command. (And in Ubiquity 0.1, ALL sources are considered untrusted, so don't take it personally!) Because Ubiquity commands can execute arbitrary javascript with chrome privileges, subscribing to a command from a website means allowing that site full access to do whatever it wants to your browser. We want to make sure people understand the dangers before subscribing to commands, so we made the warning page pretty scary."

"In the future, we're going to have something set up that we call a "trust network". When you try out a Ubiquity command from a website, and determine that the command is safe (or unsafe), you'll be able to leave an approval (or a warning). When your friends with Ubiquity installed visit the same site, they'll see the approval or the warning that you left. In this way, users will be able to rely on the judgement of other people they already know and trust in order to help them make decisions about whether a command is safe to install or not."

"By the way, the reason we call it "subscribing" to a command, rather than "installing" a command, is that if the javascript file changes -- if the site owner adds new commands, removes old commands, or updates existing commands -- all users subscribed to that URL will automatically get the updates. This will be very convenient for both users and developers, but it will also introduce another type of security risk: just because you decided a command was safe at one point in time doesn't mean that the command will always remain safe. For this reason, we'll need to make sure that the trust network keeps track of when commands have been modified, and notifies users of changes that may make a command unsafe."

Possible topics for Part 2 - ?

I plan on digging into these ideas in future posts, and have listed a few possibilities below. If you have a preference or other suggestions, feel free to leave a comment.

Using Ubiquity for Evil:
Basically, a discussion of Ubiquity features and how they could be used maliciously.

Subscription Exploits:
Results of research into whether commands could be installed in an automated fashion without the user's permission.

Ubiquity Trust Model:
Examination of how the trust model protects users from subscribing to malicious commands. This article may have to occur once that trust model has been determined by the project developers.