Luckily, I happened to run across Adventures with a certain Xen vulnerability (in the PVFB backend). Now I don't claim to be able to understand even 20% of this paper, but I was pleased to see the impact of SELinux on the attack against dom0. Very cool. Plus, unlike so much vuln work it talks about the limitations of exploits and avoids all the media whoring that tends to characterize so much vuln work these days and turns me off.
Using the above guidelines, the exploit has been built. When SELinux was in permissive mode, it worked properly, handing out a connect-back root shell. However, an unsettling message was logged:
SELinux is preventing /usr/lib/xen/bin/qemu-dm (xend_t) "execmem"
And indeed, the exploit failed when SELinux was in enforcing mode. It turns out that by default the ability to map anonymous memory with rwx protection is denied by SELinux.
Thus, the call to mmap in the return-into-libc from the previous subsection failed.
There are workarounds for "execmem" protection, dutifully explained in, but I did not nd any le that can be opened with write permission and executed in xend t domain6. So, a less ecient return-into-libc payload has been created that does not use mmap. It returns into PLT entry for execv. The arguments for execv must be rebuilt at a xed address. Using repetitive returns into "assign %eax from the stack; ret" and "stosl; ret" (these sequences must be present in the qemu-dm binary) it is possible to create a payload of size const+4*length of execv arguments.
No comments:
Post a Comment