[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUkkNhnAnbwVCk94sXv0fxEoiXVXa7kFFu-=BbMAy8Ubg@mail.gmail.com>
Date: Thu, 23 Jul 2015 06:34:50 -0700
From: Andy Lutomirski <luto@...capital.net>
To: oss security list <oss-security@...ts.openwall.com>
Subject: Re: Linux x86_64 NMI security issues
On Jul 23, 2015 6:28 AM, "Petr Matousek" <pmatouse@...hat.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
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.
