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

News
By Lucian Armasu
published

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.

Mitigation

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.

Lucian Armasu
Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
See more CPUs News
9 Comments Comment from the forums
  • 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?
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • Crystalizer
    ""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."

    How can you make better decisions if the documentation is not up to date? Yes any document could be, but it shouldn't in case of as powerful as Intel. Intel has more than enough resources to make proper documentation and the lack of documentation affects most of the population. Try doing developing with bad documentation. You will pretty soon find out after trying to solve their stuff in small amount of time can give you in to 'I rather get this fixed in time than risk getting fired situation'
    Reply
  • bit_user
    20955533 said:
    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.
    It's hard to second-guess this without actually seeing the old documentation and the changes that were made. There can be non-obvious omissions to documentation that aren't easily detectable by readers.

    Also, there are thousands of pages of docs and holding all OS developers accountable for knowing all of it and figuring out non-obvious interactions between different parts is not a reasonable expectation. In cases like these special guidance is warranted. For the vulnerability to cut across so many different OSes, it must be pretty obscure.
    Reply
  • alextheblue
    20961637 said:
    For the vulnerability to cut across so many different OSes, it must be pretty obscure.
    Bingo. This is the most telling part... if all these different major OS developers all had the same problem, I'd say the documentation was garbage.
    Reply
  • genz
    With bit and alex here.

    Obviously, Apple, Microsoft, and the hundreds of people that write basically every Linux Distro out there can't all have misread Intel documentation without Intel documentation being written in a way that either mis-states the truth or reads like it does.

    Also, this is explained in Asm commands. If it's an Assembler problem then anything lower than it is machine code and non-human readable. Key thing here is that Assembler is Assembler, there is no breaking it apart to see how it works like most programming languages because each word is directly connected to microcode and *given* from the processor verbatim. If Java had a bad bug in it's commands, Java users would open their standard libraries (programming commands list) and most of the commands would be modifiable in C++ or another lower level code if not Java itself. Old versions could be patched to remove the vulnerability for say Windows XP.

    Why is this important. Well, this is a Mov 'SS' command that moves memory from one place to another, after the next command. Intel is saying that if you try and trigger a Admin 'elevation' in the space between using the Mov word and it acually moving data, you can literally 'promote yourself' even though your PC should crash because you're calling elevation in Assembler with a User app (Ring3) and that's a too low level to get a UAC prompt let alone kernel access. You can even 'move another app's rights to yourself' if you can pin down the memory address.

    Ring0 being RT kernel ring would do things much faster, but if your program was never built to be malicious it would crash/fail on trying to do anything admin related and Admin is Ring 2. Essentially if you're a half decent programmer you would never identify this issue, because you'd expect this to obviously crash your program. So obviously in fact, that all OS developers still didn't try it.

    And if anyone wonders why someone doesn't test it anyway, there are all these to test by trying to crash them in the most obvious ways possible. You'd probably lose a few chips before you finished.
    Reply
  • Christopher1
    Better to 'lose a few chips', Genz than to have people open to a seriously security vulnerability like this one.
    Reply
  • genz
    It's not a matter of losing chips. It's a matter of it taking several million man hours to test, then perhaps several million more to clean up, when you're in a race with another company and your clients care about FAST. Even the statement 'unexpected behavior' is additive, as in the definition is 'anything that is not expected' and that can mean *anything*. (Anything is infinite, and checking infinite takes infinite time.)

    Put it this way. They try to do much more of this kind of securing on Satellite onboard processors, that's why all satellite processors in space today combined can't match a Core 2 Duo on earth. Not just for the radiation, but the bullet proof security needing super simple processor design to fully threat analyse in realistic timeframe.

    Complexity multiplies the cost of security.

    6.4 billion transistors is a big haystack to hunt needles in.
    Reply