Date: Tue, 08 May 2018 17:35:48 +0000 From: Andy Lutomirski <luto@...nel.org> To: oss security list <oss-security@...ts.openwall.com> Subject: CVE-2018-8897: #DB exceptions that are deferred by MOV SS or POP SS may cause unexpected behavior On x86 CPUs, the MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs. It appears that few or no 64-bit operating system kernels handler this correctly. On operating systems that allow users to install data breakpoints, the only correct way that a kernel can handle this CPU behavior is to use the IST mechanism for the #DB vector or to disable SYSCALL. Needless to say, the latter is unpopular. Linux has always used IST for #DB, but it used the same IST slot for #BP, so it was vulnerable to a DoS. Many other operating systems did not use IST for #DB and are likely vulnerable to privilege escalation. Some operating systems did not allow user control over hardware debugging, and they are believed to be immune. Similarly, operating systems that run hardware virtualized guests only are likely immune, since VM exits are handled differently. (However, see CVE-2018-1087 for a related issue affecting KVM.) On Linux, the issue is fixed by commit d8ba61ba58c8 ("x86/entry/64: Don't use IST entry for #BP stack"), which has been available in Linus' tree and -stable kernels for some time. (Yes, the patch really was written in 2015. I fixed the issue as part of related work by accident, but I wasn't aware that the issue was at all urgent at the time, so the patch was never pushed out.) Most other vendors should have their own advisories and fixes available now. This issue was discovered by Nick Peterson of Everdox Tech, LLC. A number of industry players coordinated very professionally to handle this issue -- thanks to all involved. A PoC for Linux can be found here: https://email@example.comfirstname.lastname@example.org
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