CVE-2015-3290: Linux privilege escalation due to nested NMIs interrupting espfix64

[Andy Lutomirski <luto () amacapital net>]

On 07/22/2015 11:12 AM, Andy Lutomirski wrote:
> +++++ CVE-2015-3290 +++++
>
> High impact NMI bug on x86_64 systems 3.13 and newer, embargoed.  Also fixed by:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a
>
> 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.
> *Patch your systems*

And here's a real advisory:

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.

A couple of notes:

 - This exploit's payload just prints the text "CPL0".  The exploit
   will keep going after printing CPL0 so you can enjoy seeing the
   frequency with which it wins.  Interested parties could easily
   write different payloads.  I doubt that any existing exploit
   mitigation techniques would be useful against this type of
   attack.

 - If you are using a kernel older than v4.1, a 64-bit build of the
   exploit will trigger a signal handling bug and crash.  Defenders
   should not rejoice, because the exploit works fine when build
   as a 32-bit binary or (so I'm told) as an x32 binary.

 - This is the first exploit I've ever written that contains genuine
   hexadecimal code.  The more assembly-minded among you can have
   fun figuring out why :)

[1] By "correctly", I mean that the register state ends up different 
from that which was saved in the stack frame, not that the 
implementation doesn't match the spec in the microcode author's minds. 
The spec is simply broken (differently on AMD and Intel hardware, 
perhaps unsurprisingly.)

--Andy

Attachment: CVE-2015-3290.c
Description: