Holes found in multiple virtualisation platforms

Local privileged escalation, virtual machine escapes possible.

Researchers have discovered vulnerabilities in a series of virtualisation software platforms that allow attackers to gain unauthorised access.

The holes could be exploited to achieve local privileged escalation and virtual machine escapes on software from vendors Xen, FreeBSD, Microsoft, and RedHat running on 64-bit operating systems on Intel processors.

Invisible Things Lab principle researcher Rafal Wojtczuk discovered the flaws, which he said allowed a ring3 attacker to craft a stack frame to be executed by the kernel after a general protection exception.

US CERT’s Jared Allar issued an alert stating that “the fault will be handled before the stack switch, which means the exception handler will be run at ring0 with an attacker's chosen RSP causing a privilege escalation”.

Users were urged to apply vendor patches. More detail is available on the US CERT advisory.

Wojtczuk detailed the following ring3 attack steps:

Map a frame at virtual address (1<<47)-4096

Any method to set the target of sysret to a non-canonical address can potentially be used. This includes ptrace, sys_sigreturn, sigaction, execve, possibly others. The best solution is to add a check for the address being non-canonical close before executing sysret. Note if the syscall handler ends with iret, then even if iret throws #GP, rsp is not controlled by the attacker, and such the situation can be handled safely.

Place a syscall instruction at address (1<<47)-2

Place SOMETHING_MALICIOUS in general purpose registers

Set rsp to AROUND_SOME_IMPORTANT_RING0_STRUCTURE

Other scenarios are possible. Whenever the #GP handler runs with usermode rsp, or does not do swapgscorrectly, code execution may be possible.

Please check your email

A confirmation email has been sent to your email address - SUPPLIED GOES EMAIL HERE. Please click on the link in the email to verify your email address. You need to verify your email before you can log on to the CRN website or start posting comments on articles.

If you do not receive your confirmation email within the next few minutes, it may be because the email has been captured by a junk mail filter. Please ensure you add the domain '@crn.com.au' to your white-listed senders.