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
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.
On Fri, Aug 8, 2008 at 7:07 PM, Chris Sears <cse...@gmail.com> wrote: > 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
On Fri, Aug 8, 2008 at 8:09 PM, Tarry Singh <tarry.si...@gmail.com> wrote: > 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
> On Fri, Aug 8, 2008 at 7:07 PM, Chris Sears <cse...@gmail.com> wrote:
>> 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
> On Fri, Aug 8, 2008 at 8:09 PM, Tarry Singh <tarry.si...@gmail.com> wrote:
>> 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
>> On Fri, Aug 8, 2008 at 7:07 PM, Chris Sears <cse...@gmail.com> wrote:
>>> 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
On Fri, Aug 8, 2008 at 1:07 PM, Chris Sears <cse...@gmail.com> wrote: > 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
On Fri, Aug 8, 2008 at 2:29 PM, Reuven Cohen <r...@enomaly.com> wrote:
> On Fri, Aug 8, 2008 at 1:07 PM, Chris Sears <cse...@gmail.com> wrote: > > 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
On Sat, Aug 9, 2008 at 1:02 AM, Khazret Sapenov <sape...@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.
> 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.
> These papers assume access to hypervisor, AMI instances(domU) do not have > access to it.
> On Fri, Aug 8, 2008 at 2:29 PM, Reuven Cohen <r...@enomaly.com> wrote:
>> On Fri, Aug 8, 2008 at 1:07 PM, Chris Sears <cse...@gmail.com> wrote: >> > 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
>> > Could have implications for those using EC2 or running/building cloud >> > services using Xen. Anyone attend it at Black Hat or have further info?
|
