Regarding Xen security....

Regarding Xen security....

[Praveen Kushwaha]

[-- Attachment #1.1: Type: text/plain, Size: 392 bytes --]

Hi Sir,

             I have a question regarding the security of Xen. What are
the security threats in with Intel VT-x.

 

 

Thanks,

Praveen Kushwaha
________________________________________________________________________
_____________________

NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno
Park, Noida | Tel: 120 436 6777 Extn 748

 

 

 


[-- Attachment #1.2: Type: text/html, Size: 5095 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Regarding Xen security....

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Praveen Kushwaha
> Sent: 12 January 2007 10:13
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Regarding Xen security....
> 
> Hi Sir,
> 
>              I have a question regarding the security of Xen. 
> What are the security threats in with Intel VT-x.

Suppose we (as a community) did know of any "exploits" in the Intel or
AMD virtualization technologies, would it make sense to distribute it to
everyone?

As far as I'm aware (and, although I work for AMD, I can't say I know
EVERYTHING, so there may be things that I'm not aware of), AMD SVM or
Intel VT-x doesn't add anything that increases security threats - in
fact they both add a level of extra security, as you can prevent the
software in the OS from actually touching hardware that you don't
explicitly give to the guest. 

Of course, broken kernel or other software will still potentially allow
a user to gain access to the guest-domain - Xen doesn't really fix
kernel security in general (it may "accidentally", but it's not there
for that purpose). Obviously, for any virtualized environment, the
security of the "host domain" (Dom0 in Xen) is critical to ensure that
the other domains remain secure - so firewalling or otherwise preventing
"outside access" to Dom0 is key to ensuring that the guest domains are
secure - but that's got nothing to do with any of the Virtualization
Technology features in the processor. 

For further improved security, both AMD and Intel have features that are
either already in the processor (AMD SVM) or planned for near-time
release (Intel's LaGrande/Trusted eXecution Technology/TXT), which allow
the execution environment to be checked before it's loaded, to ensure
that the host domain and it's relevant components are indeed what the
system owner/user expects them to be - and once that's secure, you can
then verify (or measure as it's called in security circles) the kernel
loaded as DomU. 

--
Mats
> 
>  
> 
>  
> 
> Thanks,
> 
> Praveen Kushwaha                                              
>                                                               
>                                                
> ______________________________________________________________
> _______________________________
> 
> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix 
> Techno  Park, Noida | Tel: 120 436 6777 Extn 748
> 
>  
> 
>  
> 
>  
> 
> 

Re: Regarding Xen security....

[David Pilger]

Search for "HVM rootkits", if your system runs without a hypervisor
and VMX/SVM is enabled in the BIOS then an attacker can gain control
over that layer. But he'll first need to gain control over the
operating system (not so difficult) in order to execute a program with
high privileges. In "VMX root operation" you have total control over
the system (parallel to ring0, one year ago).

VT-x is intended to provide another ring of security (priviliges),
which lets hypervisors manage unmodified operating systems.

Right now, if you are not running a hypervisor than it's not secure to
enable VT-x in the BIOS, if you do use some kind of hypervisor, then
the threat is that an attacker will find a security hole in it and
take control over that layer. Right now, there aren't any known
vulnerabilities in software the manage VMX. But I guess that the focus
of malicious people is not exactly at hypervisors. When LaGrande (for
instance) will be a part of any computer, then it will be "benefitial"
to search for vulnerabilities in this layer.

In summary, there is a risk when no hypervisor occupies the VMX layer
and it is enabled in the BIOS. The only use of this layer by a
malicious program is for properly hiding itself from removal tools.

Any way, here are some insights:
* If operating systems were secure enough and properly programmed then
VMX was not needed in this regard (to provide security).
* The implementation of VMX is here to take the control of the machine
from a certain operating system, treating an OS just like a "process".
* Its useful for servers that runs virtual machines, this is trivial
use of a hypervisors.

David.


On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote:
>
>
>
> Hi Sir,
>
>              I have a question regarding the security of Xen. What are the
> security threats in with Intel VT-x.
>
>
>
>
>
> Thanks,
>
> Praveen Kushwaha
>
>
>
> _____________________________________________________________________________________________
>
> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno  Park,
> Noida | Tel: 120 436 6777 Extn 748
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>

RE: Regarding Xen security....

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> David Pilger
> Sent: 15 January 2007 12:19
> To: Praveen Kushwaha
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Regarding Xen security....
> 
> Search for "HVM rootkits", if your system runs without a hypervisor
> and VMX/SVM is enabled in the BIOS then an attacker can gain control
> over that layer. But he'll first need to gain control over the
> operating system (not so difficult) in order to execute a program with
> high privileges. In "VMX root operation" you have total control over
> the system (parallel to ring0, one year ago).
> 
> VT-x is intended to provide another ring of security (priviliges),
> which lets hypervisors manage unmodified operating systems.
> 
> Right now, if you are not running a hypervisor than it's not secure to
> enable VT-x in the BIOS, if you do use some kind of hypervisor, then
> the threat is that an attacker will find a security hole in it and
> take control over that layer. Right now, there aren't any known
> vulnerabilities in software the manage VMX. But I guess that the focus
> of malicious people is not exactly at hypervisors. When LaGrande (for
> instance) will be a part of any computer, then it will be "benefitial"
> to search for vulnerabilities in this layer.
> 
> In summary, there is a risk when no hypervisor occupies the VMX layer
> and it is enabled in the BIOS. The only use of this layer by a
> malicious program is for properly hiding itself from removal tools.

Although it's perfectly possible to do this at present without VMX/SVM
technology. For example VMWare uses this sort of technique to make their
virtualization monitor. It's a lot more work, but it's still possible. 

The key, however, is that to use any of this, there are two conditions
required:
1. Access to run at Ring 0 - and assuming that this is not so difficult
is probably fair, but it also means that the system isn't really secure
anyways, because as soon as some arbitrary code can run in Ring 0, it's
able to do ANYTHING in the system that it likes [although it may be a
little bit of hard work to actually go from a trivial exploit to
actually gain full control over the system]. 
2. That there isn't some other use of the SVM/VMX feature in place
already - as of current, neither of these techniques are nestable, so
once some code has gained control of the SVM/VMX feature, anyone else
attempting the same thing will fail in some respect. 

--
Mats
> 
> Any way, here are some insights:
> * If operating systems were secure enough and properly programmed then
> VMX was not needed in this regard (to provide security).
> * The implementation of VMX is here to take the control of the machine
> from a certain operating system, treating an OS just like a "process".
> * Its useful for servers that runs virtual machines, this is trivial
> use of a hypervisors.
> 
> David.
> 
> 
> On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote:
> >
> >
> >
> > Hi Sir,
> >
> >              I have a question regarding the security of 
> Xen. What are the
> > security threats in with Intel VT-x.
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Praveen Kushwaha
> >
> >
> >
> > 
> ______________________________________________________________
> _______________________________
> >
> > NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix 
> Techno  Park,
> > Noida | Tel: 120 436 6777 Extn 748
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

Re: Regarding Xen security....

[David Pilger]

On 1/15/07, Petersson, Mats <Mats.Petersson@amd.com> wrote:
> The key, however, is that to use any of this, there are two conditions
> required:
> 1. Access to run at Ring 0 - and assuming that this is not so difficult
> is probably fair, but it also means that the system isn't really secure
> anyways, because as soon as some arbitrary code can run in Ring 0, it's
> able to do ANYTHING in the system that it likes [although it may be a
> little bit of hard work to actually go from a trivial exploit to
> actually gain full control over the system].
> 2. That there isn't some other use of the SVM/VMX feature in place
> already - as of current, neither of these techniques are nestable, so
> once some code has gained control of the SVM/VMX feature, anyone else
> attempting the same thing will fail in some respect.
>

Yep. saying that VT-x is unsecure in some manner is exactly like
saying that ring0 is not secure...

Re: Regarding Xen security....

[Anthony Liguori]

David Pilger wrote:
> Search for "HVM rootkits",

The vast majority of this is, as Keith Adams put its, "quasi-illiterate 
gibberish."

http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html

Having VT/SVM doesn't really change anything wrt rootkits.  Most of what 
is floating around is FUD.  There's nothing you can do today that you 
couldn't do before VT/SVM.

Regards,

Anthony Liguori


  if your system runs without a hypervisor
> and VMX/SVM is enabled in the BIOS then an attacker can gain control
> over that layer. But he'll first need to gain control over the
> operating system (not so difficult) in order to execute a program with
> high privileges. In "VMX root operation" you have total control over
> the system (parallel to ring0, one year ago).
> 
> VT-x is intended to provide another ring of security (priviliges),
> which lets hypervisors manage unmodified operating systems.
> 
> Right now, if you are not running a hypervisor than it's not secure to
> enable VT-x in the BIOS, if you do use some kind of hypervisor, then
> the threat is that an attacker will find a security hole in it and
> take control over that layer. Right now, there aren't any known
> vulnerabilities in software the manage VMX. But I guess that the focus
> of malicious people is not exactly at hypervisors. When LaGrande (for
> instance) will be a part of any computer, then it will be "benefitial"
> to search for vulnerabilities in this layer.
> 
> In summary, there is a risk when no hypervisor occupies the VMX layer
> and it is enabled in the BIOS. The only use of this layer by a
> malicious program is for properly hiding itself from removal tools.
> 
> Any way, here are some insights:
> * If operating systems were secure enough and properly programmed then
> VMX was not needed in this regard (to provide security).
> * The implementation of VMX is here to take the control of the machine
> from a certain operating system, treating an OS just like a "process".
> * Its useful for servers that runs virtual machines, this is trivial
> use of a hypervisors.
> 
> David.
> 
> 
> On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote:
>>
>>
>>
>> Hi Sir,
>>
>>              I have a question regarding the security of Xen. What are 
>> the
>> security threats in with Intel VT-x.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Praveen Kushwaha
>>
>>
>>
>> _____________________________________________________________________________________________ 
>>
>>
>> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno  Park,
>> Noida | Tel: 120 436 6777 Extn 748
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>

Re: Regarding Xen security....

[David Pilger]

On 1/15/07, Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> David Pilger wrote:
> > Search for "HVM rootkits",
>
> The vast majority of this is, as Keith Adams put its, "quasi-illiterate
> gibberish."
>
> http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html
>
> Having VT/SVM doesn't really change anything wrt rootkits.  Most of what
> is floating around is FUD.  There's nothing you can do today that you
> couldn't do before VT/SVM.
>

This is true in some manner, it's just that VT/SVM let a rootkit hide
itself pretty well from the operating system that it is already
attacking. But no doubt it's FUD. At the other end though, Intel
invests a lot of efforts in marketing VT as a synonym for security.


> Regards,
>
> Anthony Liguori
>
>
>  if your system runs without a hypervisor
> > and VMX/SVM is enabled in the BIOS then an attacker can gain control
> > over that layer. But he'll first need to gain control over the
> > operating system (not so difficult) in order to execute a program with
> > high privileges. In "VMX root operation" you have total control over
> > the system (parallel to ring0, one year ago).
> >
> > VT-x is intended to provide another ring of security (priviliges),
> > which lets hypervisors manage unmodified operating systems.
> >
> > Right now, if you are not running a hypervisor than it's not secure to
> > enable VT-x in the BIOS, if you do use some kind of hypervisor, then
> > the threat is that an attacker will find a security hole in it and
> > take control over that layer. Right now, there aren't any known
> > vulnerabilities in software the manage VMX. But I guess that the focus
> > of malicious people is not exactly at hypervisors. When LaGrande (for
> > instance) will be a part of any computer, then it will be "benefitial"
> > to search for vulnerabilities in this layer.
> >
> > In summary, there is a risk when no hypervisor occupies the VMX layer
> > and it is enabled in the BIOS. The only use of this layer by a
> > malicious program is for properly hiding itself from removal tools.
> >
> > Any way, here are some insights:
> > * If operating systems were secure enough and properly programmed then
> > VMX was not needed in this regard (to provide security).
> > * The implementation of VMX is here to take the control of the machine
> > from a certain operating system, treating an OS just like a "process".
> > * Its useful for servers that runs virtual machines, this is trivial
> > use of a hypervisors.
> >
> > David.
> >
> >
> > On 1/12/07, Praveen Kushwaha <praveen.kushwaha@nechclst.in> wrote:
> >>
> >>
> >>
> >> Hi Sir,
> >>
> >>              I have a question regarding the security of Xen. What are
> >> the
> >> security threats in with Intel VT-x.
> >>
> >>
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Praveen Kushwaha
> >>
> >>
> >>
> >> _____________________________________________________________________________________________
> >>
> >>
> >> NEC HCL System Technologies Ltd., 4th Floor, Tower B, Logix Techno  Park,
> >> Noida | Tel: 120 436 6777 Extn 748
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >>
> >>
> >>
>
>

Re: Re: Regarding Xen security....

[Mark Williamson]

> > The vast majority of this is, as Keith Adams put its, "quasi-illiterate
> > gibberish."
> >
> > http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html
> >
> > Having VT/SVM doesn't really change anything wrt rootkits.  Most of what
> > is floating around is FUD.  There's nothing you can do today that you
> > couldn't do before VT/SVM.
>
> This is true in some manner, it's just that VT/SVM let a rootkit hide
> itself pretty well from the operating system that it is already
> attacking. But no doubt it's FUD. At the other end though, Intel
> invests a lot of efforts in marketing VT as a synonym for security.

I always thought the principle behind blue pill was quite sensible.  It's not 
demonstrating a fundamental flaw / bug in the hardware design (I'm not sure 
it was originally presented that way, although I've certainly seem it treated 
as if it did).

I see it as just a (rather neat and clever) proof of concept to show that the 
VMX/SVM extensions add a new class of attack and a new stealth mechanism for 
rootkits; no more no less.  A heads-up to the security community.  And worth 
pointing out, since existing rootkit detection mechanisms may not be able to 
detect it once the VMX stealthing is enabled...

I have a feeling that this research has both been reported to be much more, 
and much less than it really is.  The important thing is that it doesn't open 
a new loophole, but does provide a new tool for attackers (and for 
defenders!).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: Regarding Xen security....

[Anthony Liguori]

Mark Williamson wrote:
>>> The vast majority of this is, as Keith Adams put its, "quasi-illiterate
>>> gibberish."
>>>
>>> http://x86vmm.blogspot.com/2006/08/blue-pill-is-quasi-illiterate.html
>>>
>>> Having VT/SVM doesn't really change anything wrt rootkits.  Most of what
>>> is floating around is FUD.  There's nothing you can do today that you
>>> couldn't do before VT/SVM.
>> This is true in some manner, it's just that VT/SVM let a rootkit hide
>> itself pretty well from the operating system that it is already
>> attacking. But no doubt it's FUD. At the other end though, Intel
>> invests a lot of efforts in marketing VT as a synonym for security.
> 
> I always thought the principle behind blue pill was quite sensible.  It's not 
> demonstrating a fundamental flaw / bug in the hardware design (I'm not sure 
> it was originally presented that way, although I've certainly seem it treated 
> as if it did).

I'm a bit bias on the subject but the author did announce her work with 
a paper claiming "100% undetectable malware".  That simply isn't true.

Discussing the practicality of hiding malware is certainly an 
interesting and research worthy topic.  However, IMHO, VT/SVM really 
doesn't make it any easier than it was in the past.

You could always hook the IDT.  That is considerably easier than setting 
up a full VT/SVM environment.

Regards,

Anthony Liguori


> I see it as just a (rather neat and clever) proof of concept to show that the 
> VMX/SVM extensions add a new class of attack and a new stealth mechanism for 
> rootkits; no more no less.  A heads-up to the security community.  And worth 
> pointing out, since existing rootkit detection mechanisms may not be able to 
> detect it once the VMX stealthing is enabled...
> 
> I have a feeling that this research has both been reported to be much more, 
> and much less than it really is.  The important thing is that it doesn't open 
> a new loophole, but does provide a new tool for attackers (and for 
> defenders!).
> 
> Cheers,
> Mark
> 

could netcard be hotplug into a running VM?

[tgh]

hi
  I have try to "xm block-attach " to hotplug a disk into a running paraVM
  and I want to kown whether the nic could be hotpluged into a running 
paraVM?
  if it could , how to do it?

could you holp me
Thanks in advance

RE: could netcard be hotplug into a running VM?

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of tgh
> Sent: 24 April 2007 07:13
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] could netcard be hotplug into a running VM?
> 
> hi
>   I have try to "xm block-attach " to hotplug a disk into a 
> running paraVM
>   and I want to kown whether the nic could be hotpluged into 
> a running 
> paraVM?
>   if it could , how to do it?

I think you're looking for "xm network-attach". 

Next time you have a question like this, maybe you could try "xm help",
as that's where I got that info from. 

[I'm only guessing from the name of the command that it does what you
want - I don't have any PV guests on my machine at the mo', so I can't
try it].

--
Mats
> 
> could you holp me
> Thanks in advance
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

Re: could netcard be hotplug into a running VM?

[tgh]

Thank you for reply and your direct




Petersson, Mats 写道:
>  
>
>   
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of tgh
>> Sent: 24 April 2007 07:13
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] could netcard be hotplug into a running VM?
>>
>> hi
>>   I have try to "xm block-attach " to hotplug a disk into a 
>> running paraVM
>>   and I want to kown whether the nic could be hotpluged into 
>> a running 
>> paraVM?
>>   if it could , how to do it?
>>     
>
> I think you're looking for "xm network-attach". 
>
> Next time you have a question like this, maybe you could try "xm help",
> as that's where I got that info from. 
>
> [I'm only guessing from the name of the command that it does what you
> want - I don't have any PV guests on my machine at the mo', so I can't
> try it].
>
> --
> Mats
>   
>> could you holp me
>> Thanks in advance
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>
>>     
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>