Xen devel - Dec 2010 - Security Implications of letting customers use their own kernel

Hi Everyone,

What are the security implications of letting customers install their 
own kernel?

In my own research, I have only seen things that would compromise their 
own DomU. My main area on concern is to protect all the other DomUs.

An area of potential concern is if someone were to build a kernel that 
enabled "No Execute" or "Disable Execution", could that
compromise other
DomUs? Or would that just leave their DomU vulnerable to running 
malicious code?

Anyone aware of anything else?

Thanks

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

> 
> Hi Everyone,
> 
> What are the security implications of letting customers install their
> own kernel?
> 
> In my own research, I have only seen things that would compromise
their
> own DomU. My main area on concern is to protect all the other DomUs.
> 
> An area of potential concern is if someone were to build a kernel that
> enabled "No Execute" or "Disable Execution", could that
compromise
other
> DomUs? Or would that just leave their DomU vulnerable to running
> malicious code?
> 
> Anyone aware of anything else?
> 
Anything that allows a DomU to compromise Dom0 is a serious security bug
and should be reported and fixed.

Once I get my hands on a proper test box I plan to do some testing on
this as during development of GPLPV I have managed to crash Dom0 due to
pre-release testing of buggy code. This probably hasn''t happened since
Xen 3.0.x though, which is ancient now, but I''d like to have some
confidence that nothing I throw at Dom0 will break it.

James


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

On Thu, Dec 16, 2010 at 3:51 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> An area of potential concern is if someone were to build a kernel that
>> enabled "No Execute" or "Disable Execution", could
that compromise
> other
>> DomUs? Or would that just leave their DomU vulnerable to running
>> malicious code?
I assume you mean a kernel that *disabled* No-Execute?  No -- Xen
should isolate decisions of individual VMs from each other (if the NX
bit can be disabled from a PV kernel at all -- I''m not sure about
that).

That said, developers certainly *aim* to make it the case that a DomU
cannot crash or gain access to Xen or Dom0 (or affect other security
measures, like NX, in any way).  However, as far as I''m aware, there
is no testing or auditing done to verify this.  And as James H. said,
buggy DomU drivers do occasionally crash dom0: and if untrusted code
can accidentally crash privileged code, it''s often the case that a
well-crafted exploit can use the same bug to gain control of the
privileged code.

 -George

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

> On Thu, Dec 16, 2010 at 3:51 AM, James Harper
> <james.harper@bendigoit.com.au>  wrote:
>>> An area of potential concern is if someone were to build a kernel
that
>>> enabled "No Execute" or "Disable Execution",
could that compromise
>> other
>>> DomUs? Or would that just leave their DomU vulnerable to running
>>> malicious code?
> I assume you mean a kernel that *disabled* No-Execute?
Yes, sorry
> No -- Xen
> should isolate decisions of individual VMs from each other (if the NX
> bit can be disabled from a PV kernel at all -- I''m not sure about
> that).
>
> That said, developers certainly *aim* to make it the case that a DomU
> cannot crash or gain access to Xen or Dom0 (or affect other security
> measures, like NX, in any way).
> However, as far as I''m aware, there
> is no testing or auditing done to verify this.
Given that Xen is used in many hosting  companies around the world, such 
as Amazon, isn''t this alarming?
> And as James H. said,
> buggy DomU drivers do occasionally crash dom0: and if untrusted code
> can accidentally crash privileged code, it''s often the case that a
> well-crafted exploit can use the same bug to gain control of the
> privileged code.
>
>   -George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 12/16/2010 01:03 PM, George Dunlap wrote:
> And as James H. said, buggy DomU drivers do occasionally crash dom0:
> and if untrusted code can accidentally crash privileged code, it''s
> often the case that a well-crafted exploit can use the same bug to
> gain control of the privileged code.
I wouldn''t be so negative. :)

I''ve definitely seen crashes of the hypervisor, but all of them were 
assertion failures rather than say a null-pointer dereference.  I''ve 
also seen denial of service bugs on the dom0 kernel which exploited bugs 
in the backend drivers.  Maybe I''m "young" as a Xen developer
(less than
2 years) but the core Xen code always seemed very robust to me.

I would hence be slightly worried of crashes and even denial of service 
on the management tools, but not so much of privilege escalation.  (A 
couple such bugs were found a few years ago by Joanna Rutkowska''s team,
but are quite rare).

That said, I wouldn''t be _more_ worried if I let customers use their
own
kernel, since they may anyway be able to use their own kernel modules if 
they have root access to the VM, so there''s almost nothing that they 
couldn''t already do before.

There is another bug that is specific of a VM environment is where 
hypervisor bugs allow a malicious user in the guest to gain access to 
ring0 in the guest (see for example CVE-2010-0419, though this one is 
for KVM).  These are the ones that would worry me the most.

Paolo

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