Date: Tue, 4 Aug 2015 13:26:38 -0700 From: Andy Lutomirski <luto@...capital.net> To: oss security list <oss-security@...ts.openwall.com> Subject: CVE-2015-3290: Linux privilege escalation due to nested NMIs interrupting espfix64 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 View attachment "CVE-2015-3290.c" of type "text/plain" (7537 bytes) text/plain

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.