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