Re: Linux x86_64 NMI security issues

[Andy Lutomirski <luto () amacapital net>]

On Jul 23, 2015 6:28 AM, "Petr Matousek" <pmatouse () redhat com> wrote:
> Hi Andy,
>
> thanks much for your summary.
>
> On Wed, Jul 22, 2015 at 11:12:00AM -0700, Andy Lutomirski wrote:
> > +++++ CVE-2015-5157 +++++
> >
> > Petr Matousek and I discovered that an NMI that interrupts userspace
> > and encounters an IRET fault is incorrectly handled.  Symptoms range
> > from an OOPS to possible corruption or privilege escalation.
>
> First of all, it was pretty much you, who discovered this issue.
>
> > I haven't verified how much corruption is possible or on what kernel
> > versions it occurs.  Some form of crash is likely in principle since
> > 3.3, and it can be triggered by the attached exploit on 3.13 or newer,
> > I believe.
>
> Why since 3.3? Is it because the nested NMI handler functionality
> introduction in 3.3?
>
> If nested NMI handler is not present, isn't this still a problem since
> the second NMI will rewrite the content of the NMI stack (and thus first
> NMI entry) and potentially overwrite the parts that are already used
> by the exception handler?

Hmm, right.  It may go back farther than that.  Also, my exploit may also
work before 3.13 -- I think I was confused when I wrote that bit.

> > On kernels that are patched for BadIRET and have a fixup_bad_iret
> > function (which should be most kernels that are keeping up with
> > low-level security issues), there are two cases.
> >
> > Case 1a (more up-to-date kernels where INTERRUPT_RETURN is "jmp
> > irq_return"): fixup_bad_iret will be invoked and will attempt to
> > recover.  There's a narrow window in which a new NMI will cause
> > corruption, in which case all bets are off.  That could hang, crash,
> > or possibly be exploited for privilege escalation.
> >
> > Case 1b (less up-to-date kernels where INTERRUPT_RETURN is "iretq"):
> > The kernel will try to OOPS due to a bad kernel fault, except that the
> > OOPS will be processed with the wrong gsbase.  This is basically the
> > BadIRET condition, and is probably exploitable using similar
> > techniques to BadIRET.
>
> Could you please explain the backtrace leading to this?  You mean the
> nested nmi return which invokes INTERRUPT_RETURN and in case
> INTERRUPT_RETURN is "iretq", error_kernelspace won't detect that and
> won't fixup the gs?

I mean the normal (non-nested) NMI return.  If we return with iretq, then
the error_bad_iret fixup won't trigger at all because that iretq
instruction has no fixup entry or swapgs special case.

--Andy

> Isn't this supposed not to fault? It says "/* No need to check faults
> here */" which doesn't mean much, but how it can fault? It always
> returns to kernel space to the NMI stack, no?
>
> Thanks,
> --
> Petr Matousek / Red Hat Product Security
> PGP: 0xC44977CA 8107 AF16 A416 F9AF 18F3  D874 3E78 6F42 C449 77CA