[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CALCETrVz9CzEYz-9EWYxEm2FAbxk6Dfhm9ZH7zcPPNP2YCdfqA@mail.gmail.com>
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://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org
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.
