Xen is a free and open source hypervisor used to create and run virtual machines. It is extensively used by cloud service providers and virtual private server hosting companies.
The security vulnerability - CVE-2014-7188 - is now patched, and was disclosed to major cloud providers last week - causing Amazon Web Services and Rackspace to reboot some of their customers' virtualised servers later in that week.
When exploited, the hypervisor flaw can let malicious virtual machines read data from - or crash - other servers. The malicious system can also potentially crash the server hosting the virtual machines.
Affected cloud providers include Amazon (Elastic Compute Cloud) and Rackspace, as well as operators using certain versions of the OpenStack cloud provisioning environment
The flaw - which was discovered last month by researcher Jan Beulich with SUSE - affects those servers that are configured to support hardware-assisted virtualisation (HVM) mode virtualisation, a technology that allows operating systems to use hardware extensions to speed up the code execution process.
According to Beulich, an application running within a virtual machine could use the software interface to read information stored outside of the VM space - effectively allowing one virtual machine to read code running on other virtual machines, as long as the instances are running on the same server. This approach is normally blocked at the operating system level.
Full details of the vulnerability were revealed to the Xen user community yesterday, after the problem was patched.
According to Gavin Millard, EMEA technical director with Tenable, the method taken by Xen to hold back on publication of the flaw until their largest customers had managed to patch it may cause some raised eyebrows in the industry, but he said he personally agrees with this approach
"When it comes to vulnerabilities that could have a huge detrimental affect similar to the Xen vulnerability that could disclose information to adjacent containers, Shellshock or Heartbleed, we must have a more mature approach to responsible disclosure to at least try to stay ahead of the attackers," he explained.
Mark James, a security specialist with ESET, was pragmatic about the flaw - and Xen's approach to releasing information after the code had been patched.
"As we strive for better and faster ways to host our ever increasing number of virtual servers, it stands to reason that we will end up in a server farm in the cloud," he said.
"Once the planning stages have taken place and the server has been installed, configured and tested, we then look at how we can protect those servers from the onslaught of attacks, malware or cybercrime that is going to happen once we publically connect the server to the Internet," he added.
In this case, however, he noted, even if you did do all you possibly could to protect the system, this particular flaw would still be outside of your direct control.
Rob Bamforth, a principal analyst with Quocirca, meanwhile, said this latest Xen security issue raises the interesting question as to who watches the watchers - "or, to put it another way, who supervises the hypervisors?"
All code is potentially buggy
All code, he explained, is potentially buggy - and with pressure to get new revisions of software out of the door as quickly as possible, things will always creep through.
"Planning and effort can minimise the impact of these issues, but taking the right approach to fixing the problems is also critical - sometimes this means staying quiet until patches are put in place and not disclosing causes for things like reboots, as has been the case with this vulnerability," he said.
Bamforth went on to say that the more that IT systems operate `in the cloud,' and so operate in the open, the more this type of issue will take place in the software community.
Rafal Wojtczuk, a security researcher with Bromium, has posted an in-depth explanation of the flaw on his latest security blog.
In that blog, he says that, whilst exploiting the problem is quite straightforward, Xen users should only need to worry about the vulnerability if they run untrusted code in their virtual machines - and also care about privilege elevation within the virtual machine environment.
The vulnerability, he explained, has the potential to crash the whole hypervisor or leak a limited amount of data from the hypervisor, but prompt patching of the program code will solve the problem in short order.