[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [Fwd: Xen 3.4 feature request (security)]
> On behalf of the Invisible Things Lab team I propose addition of the > following security features/changes into Xen 3.4 roadmap: Joanna, Thanks very much for your input, it's much appreciated. > 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. Unfortunately its reasonably tricky to do anything else as the emulated instruction needs to be executed with the contents of all registers set up as per the guest code in case the instruction is actually a communication with SMM. I guess it's only a small subset of instructions that (by convention) need that level of emulation, so we could create static code stubs for this purpose. > 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]). Yep, makes sense to tighten this up. > 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). Yep, it certainly makes sense to expose the capability set each guest has, and have an extended mode of "xm list" to display it. > 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. There are existing hypercalls to retrieve the MFN list, and it would be possible to write a user space audit tool. Actually, for debug purposes Xen already has fairly sophisticated (but slow) memory audit routines. In debug builds its possible to trigger these via a hypercall (or even 'xm'). It can spot pages that are shared and print out info on them. > We would be happy to answer/discuss any questions/doubts you might have > regarding the above propositions. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |