Fix some vulnerability issues of loading DRs and MSRs by wcwang · Pull Request #347 · intel/haxm (original) (raw)

Without resetting DR7, spurious exceptions encountered in unexpected conditions may lead to privilege escalation. The exploitability depends a lot on the host system, and how it processes #DB exceptions. Typically if the #DB handler has certain conditions that make it execute SWAPGS, then the ISR will execute with a guest-controlled TLS (the IA32_KERNEL_GS_BASE MSR, which contains a guest-controlled pointer), and here a privilege escalation is possible.

Signed-off-by: Wenchao Wang wenchao.wang@intel.com

Check the bytes being used in functions insn_fetch_*() do not exceed the 15-byte stack buffer where they are stored. It is easy for the guest to trigger out-of-bounds accesses in the host by just racing the bytes pointed to by the faulting RIP. It is an information disclosure of the host kernel stack: the out-of-bounds data has a direct influence on the instruction emulation and it doesn't seem complicated to leak host kernel stack data by observing the side effects of the altered emulation. Typically, if the destination of a MOVQ is encoded in 8 bytes located outside of the 15-byte stack buffer, the MOVQ will be applied to a destination address that is encoded by host kernel stack data. By scanning its pages to see at which address data got written, the guest can trivially infer what were the values of the 8 bytes of host kernel stack.

Signed-off-by: Wenchao Wang wenchao.wang@intel.com

When using 32-bit enum values to initialize the array of uint64_t, type casting is required. Otherwise, the upper 32 bits of each array element will be wrongly filled with 1 due to sign extension.

Signed-off-by: Wenchao Wang wenchao.wang@intel.com