[v3.0] kernel: privilege escalation due to nested NMIs interrupting espfix64 (CVE-2015-3290)
High impact NMI bug on x86_64 systems 3.13 and newer, embargoed. Also fixed by:
The other fix (synchronous modify_ldt) does not fix CVE-2015-3290.
You can mitigate CVE-2015-3290 by blocking modify_ldt or
perf_event_open using seccomp. A fully-functional, portable,
reliable
exploit is privately available and will be published in a week or two.
If an NMI returns via espfix64 and is interrupted during espfix64 setup by another NMI, the return state is corrupt. This is exploitable for reliable privilege escalation on any Linux x86_64 system in which untrusted code can arrange for espfix64 to be invoked and for NMIs to be nested.
Glossing over a lot of details, the basic structure of Linux’ nested NMI
handling is:
nmi_handler:
if (in_nmi) {
nmi_latched = true;
return;
}
in_nmi = true;
handle the nmi;
atomically (this is magic):
if (nmi_latched) {
nmi_latched = false;
start over;
} else {
in_nmi = false;
return and unmask NMIs;
}
Alas, on x86_64, there is no reasonable way to block NMIs to run the atomic part of that pseudocode atomically. Instead, the entire atomic piece is implemented by the single instruction IRET.
But x86_64 is more broken than just that. The IRET instruction does not restore register state correctly [1] when returning to a 16-bit stack segment. x86_64 has a complicated workaround called espfix64. If espfix64 is invoked on return, a well-behaved IRET is emulated by a complicated scheme that involves manually switching stacks. During the stack switch, there is a window of approximately 19 instructions between the start of espfix64’s access to the original stack and when espfix64 is done with the original stack. If a nested NMI occurs during this window, then the atomic part of the basic nested NMI algorithm is observably non-atomic.
Depending on exactly where in this window the nested NMI hits, the results vary. Most nested NMIs will corrupt the return context and crash the calling process. Some are harmless except that the nested NMI gets ignored. There is a two-instruction window in which the return context ends up with user-controlled RIP and CS set to __KERNEL_CS.
A careful exploit (attached) can recover from all the crashy failures
and can regenerate a valid privileged state if a nested NMI occurs
during the two-instruction window. This exploit appears to work
reasonably quickly across a fairly wide range of Linux versions.
If you have SMEP, this exploit is likely to panic the system. Writing a
usable exploit against a SMEP system would be considerably more
challenging, but it’s surely possible.
Measures like UDEREF are unlikely to help, because this bug is outside any region that can be protected using paging or segmentation tricks. However, recent grsecurity kernels seem to forcibly disable espfix64, so they’re not vulnerable in the first place.
Reference:
(from redmine: issue id 4575, created on 2015-08-26, closed on 2017-09-05)
- Relations:
- parent #4574