oss-security - Re: Linux x86_64 NMI security issues

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150723132828.GP15931@dhcp-25-225.brq.redhat.com>
Date: Thu, 23 Jul 2015 15:28:28 +0200
From: Petr Matousek <pmatouse@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: oss security list <oss-security@...ts.openwall.com>
Subject: Re: Linux x86_64 NMI security issues

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?

> 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?

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

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.