QEMU: user-to-root privesc inside VM via bad translation caching

This is a security issue in QEMU's system emulation for X86. The issue
permits an attacker who can execute code in guest ring 3 with normal
user privileges to inject code into other processes that are running
in guest ring 3, in particular root-owned processes.


== reproduction steps ==

 - Create an x86-64 VM and install Debian Jessie in it. The following
   steps should all be executed inside the VM.
 - Verify that procmail is installed and the correct version:
       root@qemuvm:~# apt-cache show procmail | egrep 'Version|SHA'
       Version: 3.22-24
       SHA1: 54ed2d51db0e76f027f06068ab5371048c13434c
       SHA256: 4488cf6975af9134a9b5238d5d70e8be277f70caa45a840dfbefd2dc444bfe7f
 - Install build-essential and nasm ("apt install build-essential nasm").
 - Unpack the exploit, compile it and run it:
       user@qemuvm:~$ tar xvf procmail_cache_attack.tar
       procmail_cache_attack/
       procmail_cache_attack/shellcode.asm
       procmail_cache_attack/xp.c
       procmail_cache_attack/compile.sh
       procmail_cache_attack/attack.c
       user@qemuvm:~$ cd procmail_cache_attack
       user@qemuvm:~/procmail_cache_attack$ ./compile.sh 
       user@qemuvm:~/procmail_cache_attack$ ./attack 
       memory mappings set up
       child is dead, codegen should be complete
       executing code as root! :)
       root@qemuvm:~/procmail_cache_attack# id
       uid=0(root) gid=0(root) groups=0(root),[...]

Note: While the exploit depends on the precise version of procmail,
the actual vulnerability is in QEMU, not in procmail. procmail merely
serves as a seldomly-executed setuid root binary into which code can
be injected.


== detailed issue description ==
QEMU caches translated basic blocks. To look up a translated basic
block, the function tb_find() is used, which uses tb_htable_lookup()
in its slowpath, which in turn compares translated basic blocks
(TranslationBlock) to the lookup information (struct tb_desc) using
tb_cmp().

tb_cmp() attempts to ensure (among other things) that both the virtual
start address of the basic block and the physical addresses that the
basic block covers match. When checking the physical addresses, it
assumes that a basic block can span at most two pages.

gen_intermediate_code() attempts to enforce this by stopping the
translation of a basic block if nearly one page of instructions has
been translated already:

    /* if too long translation, stop generation too */
    if (tcg_op_buf_full() ||
        (pc_ptr - pc_start) >= (TARGET_PAGE_SIZE - 32) ||
        num_insns >= max_insns) {
        gen_jmp_im(pc_ptr - dc->cs_base);
        gen_eob(dc);
        break;
    }

However, while real X86 processors have a maximum instruction length
of 15 bytes, QEMU's instruction decoder for X86 does not place any
limit on the instruction length or the number of instruction prefixes.
Therefore, it is possible to create an arbitrarily long instruction
by e.g. prepending an arbitrary number of LOCK prefixes to a normal
instruction. This permits creating a basic block that spans three
pages by simply appending an approximately page-sized instruction to
the end of a normal basic block that starts close to the end of a
page.

Such an overlong basic block causes the basic block caching to fail as
follows: If code is generated and cached for a basic block that spans
the physical pages (A,E,B), this basic block will be returned by
lookups in a process in which the physical pages (A,B,C) are mapped
in the same virtual address range (assuming that all other lookup
parameters match).

This behavior can be abused by an attacker e.g. as follows: If a
non-relocatable world-readable setuid executable legitimately contains
the pages (A,B,C), an attacker can map (A,E,B) into his own process,
at the normal load address of A, where E is an attacker-controlled
page. If a legitimate basic block spans the pages A and B, an attacker
can write arbitrary non-branch instructions at the start of E, then
append an overlong instruction
that ends behind the start of C, yielding a modified basic block that
spans all three pages. If the attacker then executes the modified
basic block in his process, the modified basic block is cached.
Next, the attacker can execute the setuid binary, which will reuse the
cached modified basic block, executing attacker-controlled
instructions in the context of the privileged process.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.