04-11-2020 | | By Robin Mitchell
Recently, researchers were able to reverse-engineer Intel CPU updates to find out the RC4 key used for microcode updates. What is microcode, what security measures can be used to protect code, and what does this discovery mean for Intel?
At the heart of a computer is the central processing unit, or CPU, which performs mathematical and logical operations. These operations are then used to perform instructions which in turn are used to execute programs. As CPUs are made up of individual logical elements, the correct sequencing of these elements is essential for the CPU to function, and these control signals are described in what is known as the microcode. Another way to understand microcode is that instructions in the instruction set architecture, such as ADD R1, R2, are used by the programmer, whereas microcode tells the CPU how to perform ADD R1, R2. In some CPUs, this could be done as enable register bank into ALU, set ALU to addition, store result in a temporary register, store the temporary register result back into register bank.
In older systems, microcode would be hardcoded into the CPU as a ROM bank or finite state machine, but modern processors can store microcode in RAM that allows for firmware updates to the CPU. This can allow for new instructions to be included as well as patches to current microcode that may contain flaws or bugs.
Many aspects of computer security revolve around keeping systems secure from external attackers that may want to steal information, install malware, or use as a zombie in large scale attacks. However, security can also be important to protect intellectual property as well as prevent attackers from identifying vulnerabilities in software. For example, Digital Rights Management, or DRM, is a system that allows software developers to protect their products from being copied and distributed without authorisation.
Another method for protecting software is to use serial keys and licenses that lock to a specific machine. While many machines exist that are identical in construction, they often have unique serial numbers, including OS key license, MAC address, and even UIDs on hardware. From there, these numbers can be combined with a special key so that the software only runs on that machine. Thus, if the program is moved to a different machine, the key won’t match the system configuration and therefore prevent the execution of the program.
Some programs are written in interpreted languages as opposed to compiled languages (examples of interpreted languages include Java, Python, and VB). Such programs, when distributed, can expose the source code as plain text, and this may allow attackers to reverse engineer the product to bypass inbuilt security measures quickly. Thus, such programs can deploy a technique call obfuscation, whereby variable names, function names, and object names are replaced with ambiguous random names. For example, the function checkSecurity() could be replaced with ersedfesf(), thus making it difficult for an attacker to understand what the purpose of the function is.
Recently, a group of researchers have managed to discover the RC4 key used by some Intel CPUs by utilising exploits in the Intel Management Engine (the exploits themselves were discovered back in 2017). The resulting discovery of the RC4 key allows the researchers to add their own microcode into Intel CPUs. Still, it should be stated that these microcode instructions are stored in RAM as opposed to ROM, thus meaning that any addition is lost on a system reboot.
Currently, the severity of the RC4 key is not clearly understood. Still, the researchers stated that the discovery of the RC4 key is the first time in history where an individual can run their own microcode on an Intel CPU. The vulnerability found in the Intel Management Engine was discovered back in 2017, and this vulnerability allows for an attacker to execute any code inside the deponent core of Intel CPUs. However, the research team took this vulnerability further and were able to put the CPU into a service mode called Red Unlock. This mode is a debugging mode that allows an engineer to test microcode, but the team were able to use it to extract the MSROM (microcode sequencer ROM). From there, the team was able to reverse engineer the ROM to understand how the microcode worked, and from there were able to determine the RC4 key used for microcode updates. The discovery of the RC4 key allows for the microcode to be updated in the CPU, but the lack of the signing key means that the updated microcode is erased on reboot.
According to Intel, none of their security measures relies on obfuscation, and the silicon itself does not hold the private key needed to update firmware permanently. However, the true extent to which this vulnerability is a problem is not clear as this is one of the first vulnerabilities discovered where microcode can be changed.
The ability to execute custom microcode can potentially allow an attacker to access any hardware on a system as they are executing instructions from the most privileged level; the silicon itself. While security systems on a CPU may be able to block signal requests to protected areas on the processor, the ability to use microcode also teaches attackers how instructions work. From there, bugs and vulnerabilities in other instructions can be quickly determined. Thus an attacker can exploit other instructions to gain access to key areas of the processor not normally accessible.