CLD-384 Details

Other IDs this deficiency may be known by:

Basic Information:

Version Specific Information:

Details:

=================================== Overview ===================================

A statement in the System Programming Guide of the Intel 64 and IA-32
Architectures Software Developer's Manual (SDM) was mishandled in the
development of some or all operating-system kernels, resulting in unexpected
behavior for #DB exceptions that are deferred by MOV SS or POP SS, as
demonstrated by (for example) privilege escalation in some Xen configurations
or FreeBSD, or a Linux kernel crash. 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.

================================ Initial Report ================================

From http://openwall.com/lists/oss-security/2018/05/08/4:

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@...nel.org/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@...nel.org

================================= Our Analysis =================================

----- Affected Products -----
Versions of the 4.9 Linux Kernel series prior to 4.9.91 are vulnerable; this was
fixed in release 4.9.91, released on 2018-03-28. This means that if you are
keeping your system reasonably up to date (i.e. you have updated since then),
you not affected; however, the Linux kernel as originally packaged in Cucumber
Linux 1.0 and 1.1 is vulnarble to this.

----- Scope and Impact of this Vulnerability -----
Allows for an unprivileged user to cause a denial of service (system crash via
a kernel panic).

----- Fix for this Vulnerability -----
This can be fixed by upgrading in Linux 4.9.91 or later or applying the patch
from commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9.

================================= Our Solution =================================

Cucumber Linux was already patched against this on 2018-03-28. No additional
action is necessary on our part; users need only update their systems to use the
latest 'linux' package.