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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ