
Xen exploitation part 1: XSA-105, from nobody to root - n3mes1s
http://blog.quarkslab.com/xen-exploitation-part-1-xsa-105-from-nobody-to-root.html
======
pklausler
TL;DR: If you can force emulation of the LGDT or LIDT instructions, you can
replace the global memory segment descriptor table or interrupt descriptor
table (resp.), since the instruction emulation code fails to check permissions
properly.

~~~
dice
Also this is privilege escalation within the DomU (guest), it does not break
out into the Dom0 (hypervisor).

It looks like he'll do one of those next, though. The last paragraph in TFA:

> A future blog post will talk about a guest-to-host escape, with a working
> exploit. Stay tuned!

------
walrus01
It's worth nothing that very few people run HVM guests on xen if they can
avoid it. The performance hit is considerable. Most xen setups I have seen are
PV guests with pygrub bootloader. Host is debian amd64, guests are also debian
amd64 or some variety of centos amd64.

~~~
sn
Using paravirtualized devices is best practice, but a combination of PV and
HVM ends up being faster for many operations - see
[http://www.brendangregg.com/blog/2014-05-07/what-color-is-
yo...](http://www.brendangregg.com/blog/2014-05-07/what-color-is-your-
xen.html) . Unfortunately HVM mode brings along QEMU which is a relatively
large amount of code, though the bugs in QEMU have tended to be lower impact
than bugs in the hypervisor itself.

While the risk from QEMU can largely be mitigated by running QEMU in a device
model stub domain, a new mode called PVH (currently being rewritten) should
theoretically be best in terms of performance, resource usage, and attack
surface. See
[http://wiki.xen.org/wiki/Xen_Project_Software_Overview#PVH](http://wiki.xen.org/wiki/Xen_Project_Software_Overview#PVH)

pygrub runs in the context of the dom0 and should not be used with untrusted
guests. Both grub legacy and grub2 work with PV mode now and there is no need
for pygrub.

