Intel's Incomplete Documentation Leads To Insecure Debugging Interface (Updated)

Update, 5/11/18, 8:30am PT: Intel denied that its documentation was incomplete, but admitted that it wasn't clear, essentially still claiming fault for the existence of the bug.

The company promised to update the documentation with more clarifying language:

The security of our customers and partners is important to us. To help ensure clear communication with the developer community, we are updating our Software Developers Manual (SDM) with clarifying language on the secure use of the POP/MOV-SS instructions. We recommend that system software vendors evaluate their software to confirm their products handle the situations in question. More information is available here.

Original, 5/9/18, 12:10pm PT:

Due to incomplete documentation from Intel, the debugging interface for its chips was not implemented correctly by operating system vendors, which resulted in a security vulnerability. The issue affects most operating systems out there, including Windows, macOS, FreeBSD, and multiple Linux distributions.

From Ring 3 To Ring 0

The CERT Coordination Center has blamed Intel for incomplete documentation for its MOV SS and POP SS interrupt/exception instructions. The MOV SS and POP SS instructions inhibit interrupts, data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction.

The issues seems to be that by misinterpreting Intel’s incomplete documentation for these instructions, the OS vendors were allowing instructions such as SYSCALL, SYSENTER, INT 3, and others that transfer control to the operating system at Current Privilege Level (CPL) < 3 to follow the MOV SS and POP SS instructions.

This would result in an unexpected behavior by allowing Ring 3 user-level applications to control the kernel Ring 0 system level. In other words, malicious apps would be able to gain control of lower-level components of the system to bypass other security protections and steal sensitive memory information.


Most OS vendors have already issued their patches to users, so you should check for updates on your operating systems and apply them as soon as possible to remain protected against this threat.

We’ve seen quite a few security bugs affecting Intel’s chips and firmware in the past year or so. The most likely explanation for this avalanche of reports is that security researchers have started taking a better look at the security of these processors, with a focus on Intel because of its market dominance.

We can also assume that because the Meltdown and Spectre flaws were first privately revealed to the OS vendors, the OS vendors have begun proactively digging deeper on all the potential security issues coming from Intel chips. To avoid many more reports like this one, or the ongoing Spectre news, Intel will need to take its security pledge very seriously in the coming years.

This thread is closed for comments
    Your comment
  • manleysteele
    Is there no one at Intel who is the person responsible for insuring that microcode and the associated assembly language does exactly what it is designed to do, and nothing else? Is there no one responsible for insuring that the vaunted Intel compiler doesn't introduce any unexpected vulnerabilities?
  • wownwow
    "allowing Ring 3 user-level applications to control the kernel Ring 0 system level."

    Any documentation could be incomplete or even have errors. Should those coders have enough experience to question or have some common sense instead of just just blindly assuming or interpreting by their own?

    Intel is responsible for not following the privilege levels well defined by itself, but the coders are responsible for this one whether the document is complete or not; ask to clarify if any doubt.
  • wirefire
    It is not the OS providers responsibility to block or inhibit the availability of low level CPU functions to the program developer. Granted in this day and age the CPU manufactures are leaning more and more on the OS to secure their hardware, if that ecosystem is going to pass the documentation on the CPU has to be very precise, as sophisticated attacks are now looking for any way to rewrite memory segments.