Subverting the Xen Hypervisor - Anyone see it at Black Hat?

[Chris Sears]

The presentation claims to demonstrate the following Xen vulnerabilities/exploits:

- practical ways to stealthly use DMA to control all physical memory
- Xen loadable backdoor modules framework - description of a set of tools allowing to easily load compiled C code into Xen hypervisor (similarly to how Linux kernel modules work)
- implementation of a backdoor residing in hypervisor space (so, invisible from the hosted operating system), allowing for remote commands execution
- implementation of a backdoor residing in a hidden, unprivileged domain, allowing for remote commands execution in dom0

https://www.blackhat.com/html/bh-usa-08/bh-usa-08-speakers.html#Wojtczuk

Could have implications for those using EC2 or running/building cloud services using Xen. Anyone attend it at Black Hat or have further info?

I also found some details on the presenting company's blog: http://theinvisiblethings.blogspot.com

 - Chris

[Tarry Singh]

I didn't know Rafal worked for/with Joanna.

As for implications, yes and no. The dangers of escape VM is and will definitely emerge as, hopefully not dramatically huge, potential risk when putting your business "out there somewhere". It may not be necessarily possible to get into it via a CloudApp but will definitely be an inside job. When firms are going full-ahead with the outsourcing their businesses to remote locations and involving third parties. There is already a potential risk with business partners who may have "other" ideas. So security wise one might think that not much would have changed but the chaging processes will also lead to bleeds and eventual breaches.

Xen's vulnerabilities and VMware ESX, which as predicted by The451Group will get compromised this year, are going to be there, pretty much similar to other internal and 3rd party breach scenarios. Stuff like bluepill, rootkits and other emerging vulnerabilities will also emerge out of poorly baselined and secured platform.

/TS

--
Kind Regards,

Tarry Singh
______________________________________________________________
Founder, Avastu: Research-Analysis-Ideation
"Do something with your ideas!"
http://www.avastu.com
Business Cell: +31630617633
Private Cell: +31629159400
LinkedIn: http://www.linkedin.com/in/tarrysingh
Blogs: http://tarrysingh.blogspot.com

[Tarry Singh]

Prezos are here BTW: http://invisiblethingslab.com/bh08/

[Tarry Singh]

Deck 2, pages 18-23 have some slides removed at Intel's request, how original!

[Reuven Cohen]

Chris, thanks for for sharing the link. If this stuff is true, it
could pose some serious problems for Amazon or any other Xen hosters..

ruv

[Khazret Sapenov]

These papers assume access to hypervisor, AMI instances(domU) do not have access to it.

[Chris Sears]

On Sat, Aug 9, 2008 at 1:02 AM, Khazret Sapenov <sap...@gmail.com> wrote:

These papers assume access to hypervisor, AMI instances(domU) do not have access to it.

They assume access to dom0, which is different than having access to the hypervisor itself. I'm not sure if Xen or Hyper-V consider there to be a security boundary between the hypervisor and the dom0/parent partition. I suspect not.

So EC2 users don't need to panic, but this kind of thing is worth being aware of. It does underscore how critical it is to secure dom0. Hopefully Amazon and any other providers using Xen already have extensive traditional security mesures in place to protect the dom0 on each physical server.

The scary possibility is a hacker finding a chink in that dom0 security and mass owning thousands of EC2 servers with customer VMs being totally incapable of defending themselves. That kind of massive reward will make dom0 a very attractive target.

 - Chris

[Randy Bias]

On Aug 9, 2008, at 10:58 AM, Chris Sears wrote:
>
> The scary possibility is a hacker finding a chink in that dom0
> security and mass owning thousands of EC2 servers with customer VMs
> being totally incapable of defending themselves. That kind of
> massive reward will make dom0 a very attractive target.

None of the Amazon dom0s are network accessible. Most likely the dom0
is tied to a completely separate NIC and remote access to it is mostly
impossible without a major good on Amazon's part. If they are being
particularly paranoid they are likely pro-actively scanning to make
sure none of their dom0s suddenly become accessible.

I'd be most concerned about mis-configuration issues that expose the
dom0 or insider attacks. Either one is fairly unlikely in the grand
scheme of things.

--Randy

Randy Bias, Founder, CloudScale
(877) 636-8589, ran...@cloudscale.net
blog: http://neotactics.com/blog

[Sassa NF]

These papers suggest there is a way to escape from domU to dom0 (see
references to pygrub)

Sassa

2008/8/9 Khazret Sapenov <sap...@gmail.com>: