While the title of this writing is somewhat reminiscent of the one used in the initial presentation Space Opera Star Trek, I must say that I am not writing about science fiction.
To get started, I think I can say that computer security is a big headache. It is a battle that is currently waged on different fronts, all with greater or lesser vulnerability, and we can be sure that all these fronts have a back door waiting to be found and exploited.
On the other hand, in computing, the concept of security is supported on four basic pillars: integrity, confidentiality, availability and authentication.
Integrity: It is the quality of the information to be correct, keeping your data exactly as it was generated, without manipulation or alteration by third parties.
Confidentiality: It is the quality of the information not to be disclosed to people or unauthorized systems.
Availability: It is the quality of the information to be accessed when required by using the appropriate channels.
Authentication: It is the quality of the information that allows to identify the generator of this. Guarantees the originality and integrity of the data.
All of the above works very well thanks to the different available encryption resources (certificates or digital signatures, asymmetric keys, etc.) and to a certain extent the reliability is supported by complex mathematical algorithms and the security offered by the underlying hardware, which is the which finally provides all the necessary physical infrastructure (mathematical calculation, storage, communication channels, etc.).
And I write to a certain point because it is assumed that the final active element, the processor, is immune and unaffected by attacks and intrusions that alter and/or modify its internal functioning. After all, it is composed of millions of transistors and hardwired logic, and all that has been fixed with a lot of chemical and photolithographic process, and is unmodifiable … hummm … unmodifiable? Well … yes … but … no …
Do not? Why not?
Recently, exploring the recent presentation at the 34th Chaos Communication Congress (34C3), I was especially struck by a so-called “Everything you want to know about x86 microcode, but might have been afraid to ask”, which among other things exposes how it is feasible modification of the behavior in some of the high level instructions in a microprocessor (Intel or AMD for more signs) modifying the microcode.
And … What is the microcode?
By definition, microcode is a look-up table for certain types of highly specialized instructions, which is translated into a set of micro instructions. It can be interpreted as a macro instruction translated into a sequence of simpler instructions.
The reason for the existence of the microcode was initially the need to lower the costs of silicon development and reduce as much as possible the hardwired area that contains the fixed instructions of the processor. With the advancement and improvements in performance in the new designs it was necessary to use more complex instructions, but at that time the integration capacity was limited (space available in silicon). The solution was that the more complex instructions were executed using a micro program composed of a sequence of simpler instructions, already existing in the processor’s instruction sequencer.
The CISC architecture, widely used by Intel and AMD, supports its most complex instructions using this scheme. It’s easy to see that in the background, the instruction sequencer of these processors is really RISC architecture.
This work methodology did not pose any problem in practice, because the microcode table was also recorded in a fixed form in the processor core, in a special area for it. All this went well until the disastrous FDIV error occurred in the Pentium processors in 1994. This meant reconsidering the way of handling this table to overcome new errors in the future, and it was decided to create a volatile memory area in the processor, in which upon starting the processor the hardcoded microcode table is copied, but leaves open the possibility that this memory area can be overwritten by an update by the BIOS or the KERNEL of the operating system.
The microcode format is not only very specific for the processor model to which it is applied, but it is also very different as applied by each manufacturer. It is also logical to think that making this change in said table is not easy, it is encrypted, and it is proprietary technology.
Intel has published the method by which an operating system or a BIOS of the motherboard can update the microcode (the contents of the microcode are not documented and the update patch is encrypted), which should be done after each start of the computer and that the update are kept in RAM. This entire update process is specified in The Intel® 64 Software Developer’s Manual and IA-32 Architectures (volume 3a) which describes the update procedure in section 9.11.
Returning to the paper in 34C3, in the talk live methods of reverse engineering are exposed in order to discover the semantics and behavior of the x86 microcode, providing sample programs and the necessary means to carry out this task. For this purpose, they used microcode samples from older processors (2013) which do not have a strong cryptographic protection and facilitated the creation of customized updates.
From the summary of this presentation, and from my point of view, two aspects were key:
“… we started to analyze the behavior of the CPU with our own updates and we used these observations to infer the microcode semantics. After a while, we had enough inverse engineering knowledge semantics to write our own microcode programs. These programs range from very simple concept tests to furtive backdoors and defensive primitives. “
“… we also perform hardware analysis. By doing the CPU delayering and visualizing it with an optical microscope and an electron microscope, we were able to locate and read the ROM that contains the microcode. After processing and reordering the physical connections, we recover the microcode of the CPU. This gave us more information about what can be done with microcode and allowed us to obtain more information about the expected behavior than our reverse engineering approach. “
Reverse engineering in microcode is not new. This topic was addressed recently in the 26th USENIX Security Symposium (USENIX Security ’17), and its security risks were discussed in the article Security Analysis of x86 Processor Microcode in 2013.
I must admit that all these activities are not easy to reach, difficult to execute, and additionally, companies like Intel or AMD will not help this to be accessible, but the precedent that can be done exists, there is an applicable method, and it is Hopefully, new methods will emerge in the future that can take advantage of security errors or omissions.
References:
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe
https://repository.asu.edu/items/22342