57 lines
No EOL
2.2 KiB
Text
57 lines
No EOL
2.2 KiB
Text
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1149
|
|
|
|
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://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42046.zip |