Intel's Incomplete Documentation Leads To Insecure Debugging Interface

[Lucian Armasu]

OS vendors left a security hole in their implementation of a debugging interface for Intel's chips. The bug seems to have been caused by a misinterpretation of Intel's incomplete documentation.

Intel's Incomplete Documentation Leads To Insecure Debugging Interface : Read more

 

[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.

 

[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'

 

[bit_user]

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.

 

[alextheblue]

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.

 

[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.

 

[Christopher1]

Better to 'lose a few chips', Genz than to have people open to a seriously security vulnerability like this one.

 

[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.