WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Regarding Xen security....

To: "David Pilger" <pilger.david@xxxxxxxxx>, "Praveen Kushwaha" <praveen.kushwaha@xxxxxxxxxxx>
Subject: RE: [Xen-devel] Regarding Xen security....
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Mon, 15 Jan 2007 13:55:12 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 15 Jan 2007 04:55:04 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <280848580701150418q46ad0dedtcd250f5f4632914c@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc4n2aLb9KOgXWpQ4O/D0LocjDMZQABGF1g
Thread-topic: [Xen-devel] Regarding Xen security....
 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> David Pilger
> Sent: 15 January 2007 12:19
> To: Praveen Kushwaha
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> >
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



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