15 February 2010

Trend Micro abandons Intercloud™ trademark application

Just when I thought we were going to be looking at another trademark debacle not unlike Dell's attempt at "cloud computing" back in 2008 (see Dell cloud computing™ denied) it seems luck is with us in that Trend Micro have abandoned their application #77018125 for a trademark on the term Intercloud (see NewsFlash: Trend Micro trademarks the Intercloud™). They had until 5 February 2010 to file for an extension and according to USPTO's Trademark Document Retrieval system they have now well and truly missed the date (the last extension was submitted at the 11th hour, at 6pm on the eve of expiry).

Like Dell, Trend Micro were issued a "Notice of Allowance" on 5 August 2008 (actually Dell's "Notice of Allowance" for #77139082 was issued less than a month before, on 8 July 2008, and cancelled just afterwards, on 7 August 2008). Unlike Dell though, Trend Micro just happened to be in the right place at the right time rather than attempting to lay claim to an existing, rapidly developing technology term ("cloud computing").

Having been issued a Notice of Allowance both companies just had to submit a Statement of Use and the trademarks were theirs. With Dell it was just lucky that I happened to discover and reveal their application during this brief window (after which the USPTO cancelled their application following widespread uproar), but with Trend Micro it's likely they don't actually have a product today with which to use the trademark.

A similar thing happened to Psion late 2008, who couldn't believe their luck when the term "netbook" became popular long after they had discontinued their product line by the same name. Having realised they still held an active trademark, they threatened all and sundry over it, eventually claiming Intel had "unclean hands" and asking for $1.2bn, only to back down when push came to shove. One could argue that as we have "submarine patents", we also have "submarine trademarks".

In this case, back on September 25, 2006 Trend Micro announced a product coincidentally called "InterCloud" (see Trend Micro Takes Unprecedented Approach to Eliminating Botnet Threats with the Unveiling of InterCloud Security Service), which they claimed was "the industry’s most advanced solution for identifying botnet activity and offering customers the ability to quarantine and optionally clean bot-infected PCs". Today's Intercloud is a global cloud of clouds, in the same way that the Internet is a global network of networks - clearly nothing like what Trend Micro had in mind. It's also both descriptive (a portmanteau describing interconnected clouds) and generic (in that it cannot serve as a source identifier for a given product or service), which basically means it should be found ineligible for trademark protection should anyone apply again in future.

Explaining further, the Internet has kept us busy for a few decades simply by passing packets between clients and servers (most of the time). It's analogous to the bare electricity grid, allowing connected nodes to transfer electrical energy between one another (typically from generators to consumers but with alternative energy sometimes consumers are generators too). Cloud computing is like adding massive, centralised power stations to the electricity grid, essentially giving it a life of its own.

I like the term Intercloud, mainly because it takes the focus away from the question of "What is cloud?", instead drawing attention to interoperability and standards where it belongs. Kudos to Trend Micro for this [in]action - whether intentional or unintentional.


09 February 2010

Introducing Planet Cloud: More signal, less noise.

As you are no doubt well aware there is a large and increasing amount of noise about cloud computing, so much so that it's becoming increasingly difficult to extract a clean signal. This has always been the case but now that even vendors like Oracle (who have previously been sharply critical of cloud computing, in part for exactly this reason) are clambering aboard the bandwagon, it's nearly impossible to tell who's worth listening to and who's just trying to sell you yesterday's technology under today's label.

It is with this in mind that I am happy to announce Planet Cloud, a news aggregator for cloud computing articles that is particularly fussy about its sources. In particular, unless you talk all cloud, all the time (which is rare - even I take a break every once in a while) then your posts won't be included unless you can provide a cloud-specific feed. Fortunately most blogging software supports this capability and many of the feeds included at launch take advantage of it. You can access Planet Cloud at:


Those of you aware of my disdain for SYS-CON's antics might be surprised that we've opted to ask for forgiveness rather than permission, but you'll also notice that we don't run ads (nor do we have any plans to - except for a few that come to us via feeds and are thus paid to authors). As such this is a non-profit service to the cloud computing community intended filter out much of the noise in the same way that the Clouderati provides an fast track to the heart of the cloud computing discussion on Twitter. An unwanted side effect of this approach is that it is not possible for us to offer the feeds under a Creative Commons license, as would usually be the case for content we own.

Many thanks to Tim Freeman (@timfaas) for his contribution not only of the planetcloud.org domain itself, but also of a comprehensive initial list of feeds (including many I never would have thought of myself). Thanks also to Rackspace Cloud who provide our hosting and who have done a great job of keeping the site alive during the testing period over the last few weeks. Thanks to the Planet aggregator which is simple but effective Python software for collating many feeds. And finally thanks to the various authors who have [been] volunteered for this project - hopefully we'll be able to drive some extra traffic your way (of course if you're not into it then that's fine too - we'll just remove you from the config file and you'll vanish within 5 minutes).

Announcing OpenECP: Open Elastic Computing Platform

I am pleased to announce the immediate availability of the Open Elastic Computing Platform (OpenECP) Version 4.0 Alpha (openecp-4.0alpha.tar.gz), provisionally tested on Debian GNU/Linux 5.0 (screenshots). This is an open source fork of the Enomaly ECP product following its abrupt commercialisation in November 2009, which resolves a number of serious security vulnerabilities. For more information refer to:

OpenECP is a web-based management platform for Linux-based hypervisors including KVM and Xen which can be used to create "public" and "private" cloud computing environments.

It will always be freely available under the Affero General Public License v3 or similar.

Features
  • Xen, KVM, Qemu, OpenVZ, Amazon EC2 support
  • Multiple OpenECP server support
  • RESTful Web Services API
  • Dashboard with metering, chargeback
  • Automated virtual machine (VM) deployment
Support
Technical support is provided by the community, however as an open source product anyone is free to support and extend it.

Background
This release was forked from the most recent version of Enomaly ECP as at 2010-02-09 (3.0.4 with a number of additional revisions), as distributed under the Affero GPL v3 by Enomaly, Inc. In order to avoid any potential intellectual property issues, all references to Enomaly™ have been scrubbed from the distribution (in the same way that references to RedHat have been purged from CentOS).

The unmodified Enomaly ECP code (enomaly-ecp-3.0.4.1.tar.gz) is also available along with a non-maintainer release which resolves all known security issues (enomaly-ecp-3.0.4.2.tar.gz) as it appears that Enomaly have no plans to address these outstanding issues.

Update: Enomaly have responded with this comparison chart (however this changelog proves a common lineage):

03 February 2010

Private cloud security is no security at all

It's ironic that the purveyors of "Private Cloud" sell their wares on the premise of enhanced privacy and security - a totally unjustified claim which is too often accepted without question - and that they are quick to dismiss the huge benefit of the armies of security boffins employed by "public" cloud vendors (whose future is largely dependent on keeping customer data safe). It's also very convenient for them that the term itself is disparaging of "public" cloud in the same way that "Blog With Integrity" badges imply that the rest of us are somehow unethical (one of the main reasons I personally have and will always dislike[d] it).

It is with that in mind that I was intrigued by Reuven Cohen's announcement today regarding Enomaly, Inc. having recently joined the Intel Cloud Builder Program (whatever that is). It was these two quotes that I found particularly questionable regarding their Enomaly ECP product:
  1. Intel was among the first to full(sic) understand the opportunity in enabling a truly secure virtualized cloud computing environments(sic) for service providers and Telco's.
  2. Our work with the Intel Cloud Builder Program will help to accelerate our efforts to deliver a massively-scalable, highly-available, high-security cloud platform to our customers.
The reason I'm naturally suspicious of such claims is that I've already discovered a handful of critical security vulnerabilities in this product (and that's without even having to look beyond the startup script - a secure-by-default turbogears component that was made insecure through inexplicable modifications):
  1. CVE-2008-4990 Enomaly ECP/Enomalism: Insecure temporary file creation vulnerabilities
  2. CVE-2009-0390: Argument injection vulnerability in Enomaly Elastic Computing Platform (ECP)
  3. Enomaly ECP/Enomalism: Multiple vulnerabilities in enomalism2.sh (redux)
I had to dig a little (but not much) deeper for the silent update remote command execution vulnerability. I also inadvertently discovered another serious security vulnerability (sending corporate BestBuy credentials in the clear over the Internet to a 3rd party service), which as it turns out was also developed by Enomaly, Inc. It's only natural that I would be suspicious of any future security claims made by this company.

It doesn't help my sentiment either that every last trace of the Open Source ECP Community Edition was recently scrubbed from the Internet without notice, leaving angry customers high and dry, purportedly pending the "rejigging [of their] OSS strategy". While my previous attempts to fork the product as Freenomalism failed when we were unable to get the daemon to start, having the code in any condition is better than not having it at all. In my opinion this is little more than blatantly (and successfully I might add) taking advantage of the Open Source community for as long as necessary to get the product into the limelight. Had they not filled this void others would certainly have done so, and the Open Cloud would be better off today as a result.

As part of cloud standards work I was interested in taking a look at the "secure" mechanism they developed for distributing virtual machines:
VMcasting is an automatic virtual machine deployment mechanism based on RSS2.0 whereby virtual machine images are transferred from a server to a client which securely delivers files containing a technical specification and virtual disk image.
Another bold claim that initially appeared justified by a simple but relatively sensible embedding of crytpographically strong checksums into descriptor and manifest files that were in turn digitally signed using GPG. Unfortunately no consideration was given to the secure retrieval of the archive itself (nor the RSS feed listing the archives for that matter), nor were signatures actually required by the specification, meaning that it would be trivial for an attacker to insert their own unsigned packages and/or replace existing signed packages with modified, unsigned ones. Or replaying an older, signed version of an insecure workload for that matter.

Fortunately an attacker need not even go to these lengths as despite acknowledging the need for digital signatures in the VMcasting specification, none of the security features appear to have been implemented in Enomaly ECP itself. Worse still, it won't even let you use SSL if you're sensible enough to try:
if url[0].lower not in ("http", "ftp"):
raise E2UndefinedError(_("Unknown scheme in package URL."))
Think you're safe if you keep everything on your own network (that's the whole point, right?). Don't be so sure, as the vmfeed module quietly registers these HTTP URLs for you:
Sure enough if you retrieve the first URL you'll get a feed of "virtual appliances" like this one (delivered over HTTP from Amazon S3 no less) and as expected, if you untar it you'll see that there's no signatures whatsoever. Don't get me started on the myriad vulnerabilities no doubt present within the appliances themselves given their age - packaging applications as virtual machines is a notoriously bad idea and one that I hope will be overrun by containers/platforms in the not too distant future.

But wait, there's more - being able to run workloads of your choice (e.g. trojan horses, network scanners, etc.) within your victim's network is one thing, and being able to obtain and reverse engineer their existing workloads (given there's no catering for authentication) another, but taking over the management system itself is where there's real fun to be had. Fortunately all you need to do is set the MIME type to application/python-egg rather than application/enomalism2-xvm2 and this little chestnut gets invoked, quietly unzipping and forcibly installing the supplied python module:
elif self.get_mime()==EGG_MIME:
tx.update("Installing Python egg.", 90)
target=os.path.join(settings.repodir,\
self.get_uuid().replace("-","_")+".egg")
shutil.move(filename, target)
self.install_python_egg(target)
The vmcast_modules feed currently advertises the e2_drivemounter, e2_exception and e2_phone_home modules which are all available for download, again over HTTP, from http://enomaly.com/fileadmin/eggs/.

Anyway I'm sure there'll be backpedalling, downplaying, shooting-the-messenger, etc. which is why you're reading this here rather than in a vulnerability announcement. While the bugs are obviously unconfirmed this still illustrates my point nicely - don't take it for granted that private cloud offerings are secure, and in the unlikely event that the systems themselves are secure, don't assume you or your provider can run them in a more secure fashion than a "public" cloud provider could.

Incidents like this go a long way towards realising one of my predictions for 2010 (or should I say @philww's "considered prediction") in that Private clouds will be discredited by year end.

Update: Following Enomaly, Inc.'s CEO denying access to the source, a "Strategic Advisor and Board Member" downplayed the issues (below), once again claiming "many of the items above have been addressed in [other] editions" and once again failing to provide any details or code for verification. Finally, the CTO tweeted "Seriously, reviewing software you've never tried is like reviewing book you've never read or a movie you've never watched. #Fail" and promptly blocked me.

Given Enomaly claimed to have 15,000 users some 18 months ago and 15,000 organisations more recently (both officially and unofficially), if they're to be believed then that's a lot of people left high and dry by the outstanding vulnerabilities, not to mention their having pulled the source. It's also more than enough motivation to announce the release of OpenECP: Open Elastic Computing Platform.

Whether the community run with it is yet to be seen but in any case it fills the void left by Enomaly ECP, throws stranded customers a lifeline and may just coax the company into being better behaved with respect to security issues and the open source community. Time will tell.

Update: According to Secunia "The vendor disputes the problems: reportedly, the vulnerable module is not used in any of their current products and was only used in the now unsupported 'Community Edition'". This conflicts with their "VM Repository Management" screencast which clearly shows both the offending VMcasting protocol and the offending insecure URLs in use in their commercial product: