[Pkg-xen-devel] Bug#464969: Bug#464969: xen-hypervisor-3.2-1-i386: Linux mmap()/vmsplice() exploit causes memory map corruption in hypervisor regardless of domain privilege

[Samuel Thibault]

William Pitcock, le Sun 10 Feb 2008 06:56:59 -0600, a écrit :
> On Sun, 2008-02-10 at 13:32 +0100, Bastian Blank wrote:
> > You have to show evidence that the Hypervisor crashed if the exploit
> > runs in a domU. dom0 is special and can always crash the hypervisor. A
> > stacktrace is usable to do this.
> 
> However, running the exploit does indeed cause the hypervisor to crash;

Again, that's no wonder for a dom0, but the question is "what about
domU".

> The exploit works by altering the memory map (via vmsplice()) to get
> access into kernel space.

Yes, and in such case Xen will refuse to make the memory map change and
just crash the guest.

> Since the memory map is altered in the domU, it is no longer in sync
> with the global state.

What do you call "global state"?

> Each domU is aware of the state of the other domU's

?! domUs don't know each other.

> in Xen (at least, this is what the documentation tells me,

What part of the documentation brings you to that?

> ). If one domU gets out of sync, it could cause state corruption in
> the hypervisor.

There's no reason why a domU should be in charge of keeping in sync. In
the security model of Xen, domU is _not_ trusted.

> As a result, Xen should check for this state corruption by maintaining
> a secondary copy of the memory map and ensuring that it has not been
> altered. If it has been altered, it should _probably_ kill the VM
> which did it.

It already traps and checks _all_ updates of the memory maps and kills
the VM if appropriate (but lets dom0 do whatever it wants).

Samuel