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...
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. 附件:[procmail_cache_attack.tar](https://bugs.chromium.org/p/project-zero/issues/attachment?aid=270456)
