mal-machine mark 1

Reuven at Elastic Vapor posted Introducing The Virtual Machine Trojan on a PoC tool called ViMtruder. It demonstrates Kris Buytaert's concerns on portability of malicious code inside VMs, but I still believe that downloading a random VM from an untrusted source without doing your due diligence is asking for trouble, whether or not this trojan was available.

Hosting and cloud computing are not the same thing

CNET's James Urquhart posted "FBI seizures highlight law as cloud impediment" covering two FBI seizures of hosted systems that resulted in innocent-bystander-errr-company-looses-equipment-itis (let's call this, the "digital-bystander syndrome"). Some very good points are raised on the legal issues such as the need for a cloud computing bill-of-rights that affords better protection to digital assets. Let's assume that the FBI seizure of these shared servers presents an inconvenience as it relates to business continuity. Let's ignore the issues around breach of confidentiality through exposure of financial records, customer activity, email etc... - which, as it turns out was really the crux of Liquid Motor's (one of the digital-bystanders) concern and the reason they filed a suit against the FBI (and lost, scary, no?). Fortunately their hosting company hasn't lost faith in the cloud - they posted a letter to their customers on google sites here. The security triumvirate of CIA (Confidentiality, Integrity and Availability) raises it's head and here's my two cents. This concern of potential availability impact due to equipment seizure is valid if you consider the cloud any servers you don't host on your own premises, but that's not how public clouds work. While the term "cloud computing" is still a bit fluffy, let's use Amazon EC2 and Google App Engine as examples of cloud computing. Here's Amazon and Google's product description on the survivability of the apps/data they host:

Amazon EC2 provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of Regions and Availability Zones. Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from failure of a single location.

Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. The same security, privacy and data protection policies we have for Google's applications applies to all App Engine applications. We take security very seriously and have measures in place to protect your code and application data.

So if you're truely hosting in the cloud, and assuming the FBI (or other TLA) can get into one their uber-data centres (I imagine there are an army of Mr Burn's-esque lawyers ready to be hot-dropped from orbiting death stars) and find the relevant server (see this video to get an idea of how hard that would be), it won't matter - you'll simply recover your app or server instance in a few seconds (maybe in another jurisdiction) and be off to the races. If you're simply outsourcing to a local colo, then you're out-of-luck if the TLAs grab your particular chunk of shared physical substrate. The customers in the same data centre as The Pirate Bay learned that lesson. Bottom-line, being in the cloud, the true cloud makes you far more resilient (probably almost completely immune) to the loss of a chunk of physical substrate and if you've got privacy concerns (which surprisingly wasn't reported as being a concern all in this instance) you can encrypt the virtual disk. My favourite line in the Wired article - "Only 'a bomb to the building' or, as it happens, an FBI raid, could cause the servers to go down, the company stated." Side note: I'm not convinced that we'll ever see something like a cloud computing bill-of-rights here in Canada (even though are privacy laws are stronger) for the simple fact that the law enforcement has this nifty get-out-jail free clause that basically says "it's ok as long as it doesn't bring the house of justice into disrepute" (and it's the courts who make that decision), so if in the process of seizing someone else's digital assets they'd probably be seen as clear of doing harm. If they happened to stumble across evidence of some illegal activity by the digital-bystander during the investigation of the suspected wrong-doer, they'd probably be able to prosecute (thing of this being treated equivalently to "Your honour, I saw something suspicious through the car window, so I proceeded to search without a warrant as I had reasonable cause").

On the dangers of OVF

I know it's security's job to be the boogie-man, but it bothers me when people use potential edge cases in security as reasons not do "good things" (TM). OVF in a nutshell - "The Open Virtualization Format Specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines. (OVF in more than a nutshell at DMTF) Kris Buytaert's posting cites one of his concerns with OVF is that it would serve as a vector for malware.

"A Virtual Machine image is the perfect vehicle for malware in your network … some prepares an image for you , you run it on your network, and you set loose the devil, who knows it does a networkscan in the background and sends the info"

He's absolutely right, it does allow for this, and will be abused, but I don't think that OVF will make the world a less secure place. Consider, USB drives are a vector of malware too (look at Conficker and Neeris) but they've made it easier to transfer data which probably improves productivity (or the sharing of the things you shouldn't be emailing since the boss may frown's on email delivered emails). If you're the sort that goes and acquires VM's or linux distro's or any sort of software from untrusted sources and don't perform validation exercises, it's not going to be OVF's fault that a mal-machine (TM - it's mine!!!) get's on your network. OVF was designed to provide security in the form of image integrity and package signing with a digital signature, so if anything it means that I'd know if someone had manipulated the VM package and if it actually came from a reputable source. I'd argue that if may make it even easier for automated analysis of VM's by anti-X technologies since it's easier to understand what resources are in the package. The other point about OVF encouraging VM sprawl is not something I can really comment on, but I think people tend to have lots of VM images anyways (storage is cheap) so again it's not a technology problem, it's more of process/governance framework/asset management issue. UPDATE: similar thinking I have to this one