Intel x86 Stack Handling Flaw allows kernel access

https://www.bleepingcomputer.com/news/security/multiple-os-vendors-release-security-patches-after-misinterpreting-intel-docs/
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."

Vulnerability Note VU#631579
Hardware debug exception documentation may result in unexpected behavior

Original Release date: 08 May 2018 | Last revised: 09 May 2018
Print Document
Overview

In some circumstances, some operating systems or hypervisors may not expect or properly handle an Intel architecture hardware debug exception. The error appears to be due to developer interpretation of existing documentation for certain Intel architecture interrupt/exception instructions, namely MOV to SS and POP to SS.
Description

CWE-703: Improper Check or Handling of Exceptional Conditions - CVE-2018-8897

The MOV 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 Current Privilege Level (CPL) < 3, a debug exception is delivered after the transfer to CPL < 3 is complete. Such deferred #DB exceptions by MOV SS and POP SS may result in unexpected behavior.

Therefore, 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. This may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions.

I'm always working under an admin account. Why should I care?

>>3
It means that unprivileged programs, that are launched without admin rights(thats is what windows does by default regardless of what account is in use) will get kernel access. Thats why all OSes are patched now.

>>4

All programs you run out of an admin account are privileged. It is bad idea to run any untrusted software on your hardware at all. If you really need to try something untrusted, there are emulators.

>>5
Only on Unix, Windows is advanced enough to only allow root when you "Run as admin.."

>>6

There are nice hacks that allow you to login as say TrustedInstaller.

When you're using x86, assume every program has ``kernel access.'' That's how it worked under DOS. If bolting on a bunch of crap could fix fundamental flaws, C++ would be good.

>>3,5
+1

Local privilege escalation is a feature, not a bug.

>>6
Wrong, admin accounts still exist on windows.

>>10
They are not actually admin, because they are still restricted in access. They are more like sudoers in Linux, instead of actual proper root account.

>>11
Root is restricted in access because it doesn't run its programs in ring 0.

>>12
pfft, you kids are still playing at ring 0, try going down a couple more

>>13
you need NSA, FSB and Mossad clearance to do that.