CVE-2015-3290 Andy Lutomirski discovered that the Linux kernel does not properly handle nested NMIs. A local, unprivileged user could use this flaw for privilege escalation. Introduced with linux-3.13. Fixes: - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d05041679904b12c12421cbcf9cb5f4860a8d7b (prerequisite) - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e181bb58143cb4a2e8f01c281b0816cd0e4798e (prerequisite) - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a (prerequisite) X-RedHat-Bug-URL: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-3290 CVE-2015-3291 Andy Lutomirski discovered that under certain conditions a malicious userspace program can cause the kernel to skip NMIs leading to a denial of service. This vulnerability was introduced with linux-3.3-rc1: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3f3c8b8c4b2a34776c3470142a7c8baafcda6eb0 Fix: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/nmi-backport (not synchronized yet, see http://www.openwall.com/lists/oss-security/2015/07/25/1) X-RedHat-Bug-URL: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-3291 CVE-2015-5157 Petr Matousek and Andy Lutomirski discovered that an NMI that interrupts userspace and encounters an IRET fault is incorrectly handled. A local, unprivileged user could use this flaw for denial of service or possibly for privilege escalation. Fix: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a More details: http://www.openwall.com/lists/oss-security/2015/07/22/7 And here's the main 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.) Source: http://www.openwall.com/lists/oss-security/2015/08/04/8 Stable kernels containing all the patches are not yet released.
All fixes in 4.2
