EDB-ID: 42046 | Author: Google Security Research | Published: 2017-05-22 | CVE: CVE-2017-2509 | Type: Dos | Platform: macOS | Aliases: N/A | Advisory/Source: Link | Tags: N/A | Vulnerable App: N/A |
The XNU kernel, when compiled for a x86-64 CPU, can run 32-bit x86
binaries in compatibility mode. 32-bit binaries use partly separate
syscall entry and exit paths.
To return to userspace, unix_syscall() in bsd/dev/i386/systemcalls.c
calls thread_exception_return() (in osfmk/x86_64/locore.s), which in
turn calls return_from_trap, which is implemented in
osfmk/x86_64/idt64.s.
return_from_trap() normally branches into return_to_user relatively
quickly, which then, depending on the stack segment selector, branches
into either L_64bit_return or L_32bit_return. While the L_64bit_return
path restores all userspace registers, the L_32bit_return path only
restores the registers that are accessible in compatibility mode; the
registers r8 to r15 are not restored.
This is bad because, although switching to compatibility mode makes it
impossible to directly access r8..r15, the register contents are
preserved, and switching back to 64-bit mode makes the 64-bit
registers accessible again. Since the GDT always contains user code
segments for both compatibility mode and 64-bit mode, an unprivileged
32-bit process can leak kernel register contents as follows:
- make a normal 32-bit syscall
- switch to 64-bit mode (e.g. by loading the 64-bit user code segment
using iret)
- store the contents of r8..r15
- switch back to compatibility mode (e.g. by loading the 32-bit user
code segment using iret)
The attached PoC demonstrates the issue by dumping the contents of
r8..r15. Usage:
$ ./leakregs
r8 = 0xffffff801d3872a8
r9 = 0xffffff8112abbec8
r10 = 0xffffff801f962240
r11 = 0xffffff8031d52bb0
r12 = 0x12
r13 = 0xffffff80094018f0
r14 = 0xffffff801cb59ea0
r15 = 0xffffff801cb59ea0
It seems like these are various types of kernel pointers, including
kernel text pointers.
If you want to compile the PoC yourself, you'll have to adjust the
path to nasm in compile.sh, then run ./compile.sh.
This bug was verified using the following kernel version:
15.6.0 Darwin Kernel Version 15.6.0: Mon Jan 9 23:07:29 PST 2017;
root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42046.zip
