Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs (bleepingcomputer.com)

Almost all major OS vendors released security patches yesterday after a researcher discovered that some OS makers have misinterpreted an Intel CPU debug feature and left their systems open to attacks. From a report: The vulnerability is in how the OS vendors implemented a hardware debug mechanism for Intel x86-64 architectures -- and more specifically the MOV SS and POP SS instructions. "In certain circumstances after the use of certain Intel x86-64 architecture instructions, a debug exception pointing to data in a lower ring (for most operating systems, the kernel Ring 0 level) is made available to operating system components running in Ring 3," the CERT/CC team explained in an advisory published yesterday. Explained in layman's terms, "this may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions." Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.

Comments

To be fair

[JOstrow]

If the custodians of every major OS misinterpreted the same document in the same way, shouldn't we consider that the document itself is suspect / at fault instead?

Re:Wow ...

[mikael]

The documentation can be found here on page 2876 of this PDF file

https://software.intel.com/sit...

"6-8 Vol. 3A
INTERRUPT AND EXCEPTION HANDLING
If an interrupt or exception occurs after the new SS segment descriptor has been loaded but before the ESP register
has been loaded, these two parts of the logical address into the stack space are inconsistent for the duration of the
interrupt or exception handler (assuming that delivery of the interrupt or exception does not itself load a new stack
pointer).
To account for this situation, the processor prevents certain events from being delivered after execution of a MOV
to SS instruction or a POP to SS instruction. The following items provide details:
  Any instruction breakpoint on the next instruction is suppressed (as if EFLAGS.RF were 1).
  Any data breakpoint on the MOV to SS instruction or POP to SS instruction is inhibited until the instruction
boundary following the next instruction.
  Any single-step trap that would be delivered following the MOV to SS instruction or POP to SS instruction
(because EFLAGS.TF is 1) is suppressed.
  The suppression and inhibition ends after delivery of an exception or the execution of the next instruction.
  If a sequence of consecutive instructions each loads the SS register (using MOV or POP), only the first is
guaranteed to inhibit or suppress events in this way. Intel recommends that software use the LSS instruction to
  load the SS register and ESP together. The problem identified earlier does not apply to LSS, and the LSS
instruction does not inhibit events as detailed above"

Why document the MOV SS and POP SS instructions first, when the safer option is the LSS instruction.

This seems to be the problem with technology these days. We are offered a dozen different ways of doing things in C++
or assembly language, but only one way is the fastest.