[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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)
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.
