[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [Fwd: Xen 3.4 feature request (security)]
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> Organization: Invisible Things Lab Hello, On behalf of the Invisible Things Lab team I propose addition of the following security features/changes into Xen 3.4 roadmap: 1) No self-modifying code in the hypervisor. Currently there is at least one place where the hypervisor builds a trampoline that is later executed (emulate_privileged_op() which builds a "stub" on the stack for I/O emulation). Such approach has not only a problem of being inelegant and potentially dangerous, the bigger problem is that it makes runtime verification of the hypervisor code integrity more difficult. 2) Strict application of the NX/XD bit in the hypervisor. Every page that doesn't contain code should be marked as non-executable. Currently this is not the case, as e.g. the Xen's heap is executable. There should be no pages that contain both the code and data. Strict NX application would not only make the exploitation of bugs in the hypervisor harder (as e.g. the FLASK overflow that we exploited during Black Hat last month [1]), but would also allow to create much simpler and more effective runtime integrity scanners for the hypervisor (see our Black Hat slides about the HyperGuard project done together with Phoenix [2]). 3) Make the Xen system more auditable. Currently the Xen hypervisor does not expose several important information about the system. For example the "xm list" command (and the underlying hypercall) do not present an information whether each domain is privileged or not. As a consequence it is possible for an attacker, that got access to the hypervisor, to set the privileged bit for one of the DomUs, allowing it to e.g. map memory at will from other domains to his or her domain (See [3] for details of a practical implementation of such backdoor). With current Xen implementation such Xen compromise would be undetectable. We believe such scenario could be used e.g. in the hosting scenarios, where various domains are rented to different customers. During one of our Black Hat presentation we have presented a rootkit that does just that. Note that such rootkit doesn't require modifications of any code in the hypervisor, nor adding any new code, just setting the is_privileged flag for some domain. Thus if we imagined a runtime hypervisor integrity scanner, like the mentioned above HyperGuard, it would still not detect the system compromise. To make this auditing complete, the hypervisor should also expose a set of MFNs that a given domain effectively is allowed to use (so, the set containing any MFN that is present in any page table that the domain can set as its current page table). This is to address a more complex variation of the compromise described above where, instead of privileging a domain, the attacker simply maps some MFN to the domain, e.g. by manually modifying the page tables inside the hypervisor. We would be happy to answer/discuss any questions/doubts you might have regarding the above propositions. Regards, Joanna Rutkowska Invisible Things Lab, CEO http://invisiblethingslab.com/ [1] http://theinvisiblethings.blogspot.com/2008/08/our-xen-0wning-trilogy-hi ghlights.html [2] http://invisiblethingslab.com/bh08/part2.pdf [3] http://invisiblethingslab.com/bh08/part1.pdf -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjFivoACgkQORdkotfEW84ZmgCfWRrndQHxJSPDd3lxfLaVZJO5 lasAoOUjMWNkZZEGsw2he/06BZfY1/B9 =uHhh -----END PGP SIGNATURE----- _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |