Secure Coding Practice

The general secure coding practice in the firmware is similar to the one in the software.

Secure Design Practice

Besides the secure coding practice, there are secure design practices in the firmware which are also similar to the ones in software.

Boot Firmware Secure Design Practice

Besides general design practices, we list some boot firmware-specific secure design practices.

Side Channel Attack

There is an interesting puzzle named 3 Bulbs and 3 Switches. The puzzle proceeds as follows: “There is a room with a door (closed) and three light bulbs. Outside the room, there are three switches, connected to the bulbs. You may manipulate the switches as you wish, but once you open the door, you can’t change them. Please identify each switch with its bulb.”

The solution of this puzzle cannot be reduced to a mathematical model. Logically, it seems impossible to identify which switch controls which bulb by entering the room only once because each bulb can only have one of two states – ON or OFF. There is not enough mathematical information to distinguish the different states of three bulbs. In practice, the bulb can have more than two states because of the heat. If we turn on a switch for a while, the bulb becomes hot. Even after we turn off the switch, the bulb is still hot for a while.

The heat of the bulb is a typical example of side channel information which is used to distinguish X and Z.

Another side channel example includes the classic numeric keypad wear-out issue. See Figure 14-1 which shows a worn-out numeric keypad. The numbers 3 and 7 are heavily worn out, and the numbers 4 and 8 are slightly worn out. From this, we know that 3, 4, 7, and 8 should be included in the passcode. There is a high probability that multiples of 3 or 7 exist. The wear-out is a typical example of side channel information.

Traditional Side Channel Attack

The traditional side channel attack can be pure software or hardware assisted. The software side channel attack includes a timing attack and a cache attack. The hardware side channel attack includes simple power analysis (SPA), simple electromagnetic analysis (SEMA), differential power analysis (DPA), differential electromagnetic analysis (DEMA), and so on. Some of these are used to attack the cryptographic library implementation.

Marc Witteman’s whitepaper “Secure Application Programming in the Presence of Side Channel Attacks” provides good information on this topic.

Timing Attack

Listing 14-25 shows a typical example of passcode memory compare which can be used to compare the input passcode with the expected passcode.

==========================

bool compare_mem(byte *a, size_t a_len, byte *b, size_t b_len) {

  if (a_len != b_len) { // data dependent!

    return false;

  }

  for (size_t i = 0; i < a_len; i++) {

    if (a[i] != b[i]) { // data dependent!

      return false;

    }

  }

  return true;

}

==========================

Listing 14-25.

The problem with this approach is that the function execution time is proportional to the number of chars matched in the passcode. In the first round, the attacker can construct a set of strings “a*******”, “b*******”, “c*******”, and so on as input and measure the function execution time. They may observe a significant timing difference between “P*******” and “Q*******” and then conclude the first char is “P.” In the second round, the attacker constructs a set of strings “Pa******”, “Pb******”, “Pc******”, and so on as input and measures the function execution time. A significant timing difference can be observed between “P@******” and “P#******”. Then they know the second char is “@”. Using a similar technique, the attacker uses linear time to attack all chars in the passcode one by one. See Figure 14-2.

The mitigation is to let the for-loop’s execution time become independent of the number of character matches. See Listing 14-26.

==========================

bool compare_mem (byte *a, size_t a_len, byte *b, size_t b_len) {

  volatile size_t x = a_len ^ b_len;

  for (size_t i = 0; ((i < a_len) & (i < b_len)); i++) {

    x |= a[i] ^ b[i];

  }

  return (x==0);

}

==========================

Listing 14-26.

Cache Attack

A cache side channel attack is based upon the fact that the cache access time is much faster than the memory access time. Figure 14-3 shows a single level of a set-associated cache. Each row in a memory block (memory line) is mapped to the corresponding row in the cache block (cache line). The cache line holds a copy of a subset of the memory line in cases where the memory line is accessed by the CPU. For a new memory line access, if the CPU finds the data in the cache (also known as cache hit), the CPU accesses the data in the cache directly. Otherwise, if the CPU cannot find data in the cache (also known as cache miss), the CPU loads the content from memory to the cache by evicting its previous content. The CPU also provides an instruction to flush the content out of the cache. In this case, it will always cause a cache miss during the next access. There are two common techniques used in last-level cache (LLC)–based attacks: PRIME+PROBE and FLUSH+RELOAD. Let’s see them one by one.

Prime+Probe

The PRIME+PROBE attack exploits resource contention between two processes, thus allowing an attacker process to measure the cache usage of a victim process. A round of attack includes three phases:

1. 1)

   For phase PRIME, the attacker primes the targeted cache set by accessing the cache lines in its eviction buffer. The monitored cache set is filled with the attacker’s data. See Figure 14-4.

    
2. 2)

   For phase IDLE, the attacker waits for a while to allow the victim to access the target cache line.

    
3. 3)

   For phase PROBE, the attacker probes the cache set by measuring the time to access the cache lines in the eviction buffer. If the victim accesses the target cache line in phase 2, the target cache line will evict an attacker line from the cache; then the PROBE operation will take a longer time. See Figure 14-5.

    

One example of the Prime+Probe attack is to monitor the lookup table usage in a bad AES crypto implementation and then derive the key value based upon the side channel information.

The mitigation includes removing the lookup table, using a dynamic lookup table, disabling the cache, hiding timing, and using hardware-assisted cryptographic algorithms.

Flush+Reload

The FLUSH+RELOAD attack relies on a share page between the attacker and victim processes. Both processes must have access to the same resource. A round of attack includes three phases.

1. 1)

   For phase FLUSH, the attacker flushes the target cache line from the cache hierarchy. For example, this flush can be accomplished by using the clflush instruction. See Figure 14-6.

    
2. 2)

   For phase IDLE, the attacker waits for a while to allow the victim to access the target cache line.

    
3. 3)

   For phase RELOAD, the attacker reloads the target cache line and measures the time to load. If the victim accesses the target cache line in phase 2, then the RELOAD operation will take a short time. Otherwise, the RELOAD operation takes a longer time. See Figure 14-7.

    

There are some other cache attacks, such as Evict+Time and Evict+Reload. With a cache attack, the attacker can know if the content in a specific memory location is accessed by measuring the time difference between a cache hit and a cache miss.

One example of the Flush+Reload attack is to recognize the Square-Reduce-Multiply-Reduce pattern in the bad GnuPG crypto implementation . With the side channel information, the attacker may recover the bits of the exponent.

The mitigations include but are not limited to preventing page sharing, not using special data-dependent algorithm, disabling the cache, hiding timing, and using hardware-assisted cryptographic algorithms.

Simple Analysis

Simple analysis includes simple power analysis (SPA) and simple electromagnetic analysis (SEMA) . The attacker can observe the power consumption difference or the electromagnetic signal difference to distinguish different instruction executions. Special measurement equipment is required to collect such information. ChipWhisperer is one of the open-source toolchains for side-channel power analysis and glitching attacks.

Differential Analysis

Differential analysis includes differential power analysis (DPA) and differential electromagnetic analysis (DEMA) . The attacker needs to collect a large number of trace data sets and use statistical analysis to figure out their relationships and then to derive secrets. Similar to the simple analysis, special measurement equipment is required to collect such information.

Principle of Traditional Side Channel–Resistant Coding

Intel’s whitepaper “Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations” describes the principles for the traditional side channel attacks – timing side channel and cache side channel:

1. 1)

   Secret-independent runtime (SIR)

    

Timing side channels take advantage of the smallest differences in execution time, sometimes at the resolution of a single clock cycle. We need to ensure algorithms consistently process secret data and only use instructions whose latency is invariant to the data values. The compare_mem() implementation is a typical example.

1. 2)

   Secret-independent code access (SIC)

    

The value of a secret, or values derived from a secret, must not affect a conditional branch or the target of an indirect branch. The address sequence of executed instructions must be independent of secret values. For example, if there is special squaring code for the square calculation, then the attacker can deduce the data pattern by using Flush+Reload to monitor if the squaring code has been executed. Using general multiplication to replace square calculation can mitigate this concern.

1. 3)

   Secret-independent data access (SID)

    

Secret values should not cause a change to the order of accessed addresses or the data size of loads/stores. For example, don’t use a secret value to load a specific location from a table representing an S-box without taking appropriate precautions. Care must be taken for any lookup table usage in the crypto library.

Speculative Execution Attack

Modern CPUs have introduced some advanced techniques to achieve maximum performance, such as branch prediction, speculative execution, out-of-order execution, and so on. The basic idea is to execute the next instruction in the instruction pipeline whenever it is possible and prepare the result. If this instruction needs to be executed finally, the result can be committed directly. If this instruction is not needed, then the result is discarded.

Ideally, once the result is discarded, there will be no impact to the security of the system. Unfortunately, this intermediate result may impact the cache state. Then the cache state can be exposed via the cache side channel attack we discussed in the preceding text, such as the Flush+Reload attack. Spectre and Meltdown are two famous side channel attacks. Let’s discuss them one by one.

Spectre Variant 1: Bounds Check Bypass

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.

The Spectre attack variant 1 is named bounds check bypass. Consider the code example in Listing 14-27 of a function receiving an untrusted input x. The code fragment uses a bound check on x to prevent the buffer overflow access because there might be sensitive information after the array1.

==========================

uint8 array1[ARRAY1_SIZE];

int array1_size = sizeof(array1);

uint8 array2[ARRAY2_SIZE];

uint8 secret[SECRET_SIZE];

DataProcess (int x)

{

  if (x < array1_size) {

    y = array2[array1[x] * 256];

  }

}

==========================

Listing 14-27.

If the attacker gives x = &secret[0] - &array1, then k = array1[x] = secret[0] is the first byte of secret. With speculative execution, the CPU will read the k from the secret, calculate the y, and save the value k and array2[k * 256] to the cache before the if statement is evaluated. Later after the CPU notices that the value x is out of bound, then it will discard the value y. However, the secret k and the value array2[k * 256] are still in the cache.

Now, the attacker can use the Flush+Reload attack to get the k if the array2 is readable from the attacker’s process. In phase FLUSH, the attacker flushes the cache line for the array2. Then they trigger the data process. In phase RELOAD, the attacker can try to load each byte at array2[n* 256], where n is from 0 to 255. When n == k, the reload time is very short because the data is from the cache. Otherwise, the reload time is significantly longer because the data is from memory.

The main mitigation of bounds check bypass is to use a speculation barrier instruction, such as LFENCE instruction in the X86 platform and CSDB instruction in the ARM platform when the code needs to reference the untrusted input as the index. Ideally, we hope the compiler can be smart enough to insert the speculation barrier instruction into the correct location. However, there might be false-positive or false-negative cases. As such, if possible, the developer should be aware of this issue and insert a speculation barrier instruction directly. See Listing 14-28.

==========================

uint8 array1[ARRAY1_SIZE];

int array1_size = sizeof(array1);

uint8 array2[ARRAY2_SIZE];

uint8 secret[SECRET_SIZE];

DataProcess (int x)

{

  if (x < array1_size) {

    SpeculationBarrier ();

    y = array2[array1[x] * 256];

  }

}

==========================

Listing 14-28.

For the host firmware, the system management mode (SMM) code might be impacted by the bounds check bypass. As such, the speculation barrier instruction is required for the SMM handler if it accepts any untrusted external input as array index.

Spectre Variant 2: Branch Target Injection

The Spectre attack variant 2 is named branch target injection. An indirect branch means the target address of the branch is from a register (such as jmp eax), a memory location (such as jmp [eax] or jmp [0x12345678]), or a stack location (such as ret). Listing 14-29 shows a typical indirect branch in the UEFI firmware.

==========================

  gBS->LocateProtocol (&gEfiPciIoProtocol, NULL, &PciIo);

  PciIo->AllocateBuffer (

            PciIo,

            AlloateAnyPages,

            EfiBootServicedData,

            1,

            &HostAddress,

            0

            );

==========================

Listing 14-29.

The branch target injection takes advantage of the indirect branch predictors that are used to direct what operations are speculatively executed. By influencing how the indirect branch predictors operate, a malicious attacker can cause malicious code to be speculatively executed and then measure the effects such code has on the processor cache/system memory to infer data values.

According to Intel’s whitepaper, an exploit using a branch target injection is composed of five specific elements, all of which are required for successful exploitation. Traditional application software which is not security sensitive needs to be carefully evaluated for all five elements before applying the mitigation:

1. 1)

   The target of the exploit (the victim) must have some secret data that an exploit wants to obtain. In the case of an OS kernel, this includes any data outside of the user’s permissions, such as memory in the kernel memory map.

    
2. 2)

   The exploit needs to have some method of referring to the secret. Typically, this is a pointer within the victim’s address space that can be made to reference the memory location of the secret data. Passing a pointer of an overt communication channel between the exploit and the victim is a straightforward way to satisfy this condition.

    
3. 3)

   The exploit’s reference must be usable during execution of a portion of the victim’s code which contains an indirect branch that is vulnerable to exploitation. For example, if the exploit pointer value is stored in a register, the attacker’s goal is for speculation to jump to a code sequence where that register is used as a source address for a move operation.

    
4. 4)

   The exploit must successfully influence this indirect branch to speculatively mis-predict and execute a gadget. This gadget, chosen by the exploit, leaks the secret data via a side channel, typically by cache timing.

    
5. 5)

   The gadget must execute during the “speculation window” which closes when the processor determines that the gadget execution was mis-predicted.

    

The mitigation of branch target injection can be accomplished in two ways:

1. 1)

   The first mitigation entails directly manipulating the speculation hardware. This requires a CPU microcode update and manipulation of hardware registers.

    
2. 2)

   The second mitigation involves indirectly controlling speculation behavior. Retpoline is a software construct for preventing branch target injection. It only impacts element 4 in the preceding five elements, but it is sufficient to stop the branch target injection exploit.

    

What does retpoline mean? First, let’s see Figure 14-8 – speculative execution without retpoline. If the attacker can poison the predicted target address, they can control the speculative path execution to a gadget.

The indirect branch predictor is an internal CPU structure which is invisible to software. Even operating systems cannot control the behavior of the indirect branch predictor. As such, we need a way to bypass the indirect branch predictor. We know that the prediction of RET instructions differs from that of JMP and CALL instructions because the RET instruction relies on the Return Stack Buffer (RSB). The RSB is a typical last-in-first-out (LIFO) stack which is also a CPU internal structure different from the stack in the memory. The RSB can be controlled by software. The CALL instruction pushes entries, and the RET instruction pops entries. As such, we can convert a JMP or CALL instruction to a RET instruction to force the hardware to use the RSB instead of an indirect branch predictor. See Figure 14-9.

Usually the retpoline is generated by the compiler. In some rare case, we may need to write assembly code directly. As such, we need to know how to write retpoline code.

Listing 14-30 shows a simple JMP indirect branch. Listing 14-31 shows its retpoline replacement.

==========================

  jmp [rax]

==========================

Listing 14-30.

==========================

   call load_label

capture_ret_spec:

   lfence

   jmp capture_ret_spec

load_label:

   mov [rsp], rax

   ret

==========================

Listing 14-31.

Listing 14-32 shows a simple CALL indirect branch. Listing 14-33 shows its retpoline replacement.

==========================

  call [rax]

next_instruction:

==========================

Listing 14-32.

==========================

   jmp label2

label0:

   call label1

capture_ret_spec:

   lfense

   jmp capture_ret_spec

label1:

   mov [rsp], rax

   ret

label2:

   call label0

next_instruction:

==========================

Listing 14-33.

When the CALL instruction is executed, the next instruction address is pushed to the stack and the RSB, which is capture_ret_spec. The “mov [rsp], rax” instruction only modifies the content in the stack, but not the RSB. This is very important because the memory stack and RSB differ at this point. Just in case the speculation happens at RET, it will execute the entry in the RSB, which is capture_ret_spec, instead of the rax, and then run into a dead loop. See Figure 14-10.

The RSB is a fixed-size stack implemented in hardware. It can underflow in certain conditions, thus causing undesirable behavior. When the RSB stack is empty on some processors, a RET instruction may speculate based upon the contents of the indirect branch predictor. This latter case is the situation that retpoline is designed to avoid.

According to the Intel whitepaper, there are also a number of events that happen asynchronously from normal program execution that can result in an empty RSB. Software may use a “RSB stuffing” sequence whenever these asynchronous events occur:

1. 1)

   Interrupts/NMIs/traps/aborts/exceptions which increase call depth

    
2. 2)

   System management interrupts (SMIs)

    
3. 3)

   Host VMEXIT/VMRESUME/VMENTER

    
4. 4)

   Microcode update load (WRMSR 0x79) on another logical processor of the same core

    

Listing 14-34 shows an example of RSB stuffing sequences.

==========================

void rsb_stuff(void)

{

    asm(".rept 16 "

         "call 1f "

         "pause ; LFENCE "

         "1: "

         ".endr "

         "addq $(8 * 16), %rsp ");

}

==========================

Listing 14-34.

The host firmware might not be impacted by the branch target injection if all codes run at the same privilege. On processors with different empty RSB behaviors, SMM code should stuff the RSB with CALL instructions before returning from SMM to avoid interfering with non-SMM usage of the retpoline technique.

Meltdown Variant 3

Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

Meltdown attack takes three steps:

1. 1)

   Secret read: The attacker accesses a kernel address and loads the content into a register, such as using a MOV instruction. This address is inaccessible because of the privilege. Most modern operating systems use a single page table to map the application space and the kernel space. As such, the kernel space address is present in the page table. Because of out-of-order execution, the CPU loads the kernel data internally at first regardless of the privilege. Later when the MOV instruction retires, the exception is triggered. However, there is a race condition between the raising of the exception and the secret transmit step.

    
2. 2)

   Secret transmit: The attacker uses a transient instruction sequence to access a cache line based on the secret content of the register. If this transient instruction sequence is executed before the MOV instruction is retired in the race condition and the transient instruction sequence performed computations based on the secret, it can be utilized to transmit the secret to the attacker.

    
3. 3)

   Secret receive: The attacker uses the Flush+Reload attack to determine the accessed cache line and then gets the secret content.

    

Listing 14-35 shows the code example of the Meltdown attack. With this approach, the application can dump the whole kernel memory content.

==========================

  ; rcx = kernel address

  ; rbx = probe array

retry:

  mov al, byte [rcx]

  shl rax, 0xc

  jz retry

  mov rbx, qword [rbx + rax]

==========================

Listing 14-35.

The mitigation of Meltdown is to set up dual page tables, also known as kernel page table isolation (KPTI). One page table is designated for the user-level application, with a minimal kernel page for the context switch only. The other page table is only for the OS kernel usage. With the dual page tables, the Meltdown attack will fail in the secret read because the user mode paging does not have a valid address for the OS kernel. There is no way to read the OS kernel content. We will introduce more details in Chapter 16.

If the firmware enables the kernel mode and user mode isolation, the dual page tables should be used to resist the Meltdown attack.

Others

Besides the original Spectre variant 1 and variant 2 and Meltdown variant 3, there are more and more side channel attacks appearing, such as variant 3a, Rogue System Register Read; variant 4, Speculative Store Bypass; SpectreRSB; BranchScope; and so on.

The Spectre and Meltdown website lists all impacted products, including the processors, such as X86 and ARM, and operating systems, such as Linux and Windows. The following documents describe some technical details of the issue and the mitigation:

• Intel, “Host Firmware Speculative Execution Side Channel Mitigation”

• Intel, “Deep Dive: Analyzing Potential Bounds Check Bypass Vulnerabilities”

• Intel, “Deep Dive: Retpoline – A Branch Target Injection Mitigation”

• Intel, “Security Best Practices for Side Channel Resistance”

• ARM, “Cache Speculation Side-channels”

• Google, “Retpoline: a software construct for preventing branch-target-injection”

• Linux, “KAISER: hiding the kernel from user space”

• Microsoft, “Spectre mitigations in MSVC”

• Microsoft, “Mitigating Spectre variant 2 with Retpoline on Windows”

Besides the cache, other micro-architecture may also be vulnerable to the speculative attack, such as Intel Microarchitecture Data Sampling (MDS). Intel MDS involves Microarchitecture Store Buffer Data Sampling (MSBDS), Microarchitecture Fill Buffer Data Sampling (MFBDS), Microarchitecture Load Port Data Sampling (MLPDS), and Microarchitecture Data Sampling Uncacheable Memory (MDSUM). The key concept of MDS is that the CPU microarchitecture includes one or more special data buffer in the memory pipeline besides the CPU cache. These special data buffers are vulnerable to cache speculative attack, such as FLASH+RELOAD. The Rogue In-Flight Data Load (RIDL) showed the attack to leak in-flight data from the line-fill buffer. The fallout demonstrated the attack the data leakage from the store buffer. Those attacks can bypass the existing cache speculative mitigation. Intel whitepaper “Deep Dive: Intel Analysis of Microarchitectural Data Sampling” provides more detailed information on MDS.

Please always refer to the latest side channel mitigation guidelines.

Fault Injection

Fault injection entails the generation of unexpected conditions and triggering of a fault. In general, it includes software fault injection and hardware fault injection. The software fault injection can be compiler time or runtime. The compiler-time fault injection is to add some stub functions to trigger the error path. Usually, it is used to test the robustness and error handling code. The runtime software fault injection is similar to the untrusted external input. It can be used in both the penetration test and real attack. It is already covered in the previous section – “Check Input Cross Trust Boundary.”

Hardware fault injection involves the modification of the physical environment by placing the hardware chip in an unusual situation. It could be overvoltage, under-voltage, voltage glitch, electromagnetic pulse, high-energy radiation, high temperature, low temperature, and so on. A typical hardware fault injection brings a transient effect, such as flipping a single bit or a few bits, to skip an instruction or control a branch path. It is very effective to bypass the security check. In the real world, we have seen row hammer attacks or glitch attacks to bypass the security checking and gain privilege. The real open source example includes ChipWhisperer and SySS iCEstick Glitcher, etc. Our focus in this section is to discuss the mitigation for the hardware fault injection.

This function is vulnerable to the glitch attack if the attack can flip 1 bit between “Test (&Action)” and “switch (Action).” In cases wherein the test function finds some errors and sets Action to be an abnormal one, such as EfiDriverConfigurationActionStopController (1), the attacker can flip the Action bit0 to 0 in order to let this code just continue running. If the test function sets the Action to be EfiDriverConfigurationActionRestartController (2), the attacker can flip the Action bit1 to 0. If the Action is set to EfiDriverConfigurationActionRestartPlatform (3), then the attacker cannot flip the Action to 0. However, the attacker can flip the Action bit31 to 1 to make it invalid. Because the default path in the switch is continued, this code just continues running with the invalid action.

First, the enum definition should use a non-trivial value with a large Hamming distance. The Hamming distance between two numbers is defined as the number of bits that differ for those numbers. For example, the pair (0, 1) has a Hamming distance 1. (0x5A=0101_1010b, 0x3C=0011_1100b) has a Hamming distance 4. (0x5A=0101_1010b, 0xA5=1010_0101b) has a Hamming distance 8. A large Hamming distance makes it hard for the attacker to change from one value to the other value. Second, we handle the undefined state in the default path and treat it as a failure condition. This makes it difficult for the attacker to take advantage of success by default.

Listing 14-39 shows the improvement. First, it uses the non-trivial definition for the final result instead of a BOOLEAN. As such, it is hard for the attacker to flip the result. Second, it adds a redundancy check. For example, the authentication function is called twice as a double check. The attacker must flip bits in two different places. Third, it uses a random delay before any check function, which makes it hard for the time-based fault injection.

External Input

Checking the untrusted external input across the trust boundary is rule number 1.

What entails untrusted external input should be defined clearly based upon the threat model. You may ask yourself, can the attacker control and modify the data? If yes, then it is untrusted external input. If no, then it is probably trusted data. Some external input data are very clear, such as a BIOS logo Bitmap (BMP) file or Joint Photographic Experts Group JPEG file, a BIOS update image, content in the file system, the trusted execution environment (TEE) communication buffer, network packet, and so on. Some external input data may be trusted or untrusted, such as a recovery image. If the system designer puts the recovery image into an immutable location and only allows manufacturing mode update, then this image could be treated as trusted. If the system designer allows the end user to put a recovery image in any allowed recovery media, such as the hard disk or USB disk, then the input is untrusted. Another example is the flash content. If the threat model includes the simple hardware adversary and assumes the attacker may use a flash programmer to update the flash content directly, then it is untrusted and should be validated by a platform Root-of-Trust. If the threat model does not include simple hardware adversary but only includes a system software adversary, then we can just apply flash write protection in the TEE. The flash content can be treated as trusted in the boot.

The concept of trusted internal input and untrusted external input may change in the production. For example, in old days, the BMP logo file was treated as the internal input. The end user cannot modify the BMP BIOS boot logo file. Later, some BIOS treated it as a feature to allow an end user to customize the BIOS boot logo. Then the BMP logo file becomes an untrusted external input. The universal plug and play (UPnP) protocol is designed to be used in a trusted local area network (LAN) and the protocol does not implement any form of authentication or verification. However, many common Internet-connected devices support UPnP. The attacker found the vulnerabilities, such as CallStranger. Then the Open Connectivity Foundation (OCF) has updated the UPnP specification to address this issue. If the previous assumption is changed, the external input for the production must be reevaluated.

When we perform the input check, the secure coding practices should be followed. Per our observation, buffer overflow, arbitrary buffer access, and arithmetic error such as integer overflow are the top three issues. Care must be taken for them. If the input check is missing or incomplete, there is a high risk of privilege escalation. This usually happens during the firmware update process or in a trusted execution environment (TEE) handler, such as X86 system management interrupt (SMI) handler or ARM secure monitor call (SMC) handler. The input validation is critical for the TEE to resist the confused deputy attack because of the high privilege of the TEE.

Correct error handling is also important. For example, if the check function fails to find the policy, it should return a verification failure instead of a verification pass. Especially in cases where the check function fails to find the revocation policy or denied image policy due to expected system error or hardware error, it should still also return verification fail. Only if the check function fails to find the revocation policy or denied image policy because the policy is valid but empty should it return a verification pass. Missing error handling is not a good choice. ASSERT may be used to define the contract clearly. Before using ASSERT, please always ask yourself: Might this occur when the attacker tries to attack the system and modify the software or hardware state? Or is this a case that never occurs because it is guaranteed by the other code logic or hardware restriction? ASSERT should only be used in the latter case. Error handling should be used for the former case.

The compatibility support might be a burden because the old image format or signature format might be different from the latest one. It is highly recommended to use a different function and different code path to cover the compatibility support instead of mixing the logic with the latest format. We have seen bad examples where the code combines both logic flows together and thus makes it very complicated. With such complexity, a small mistake in the compatibility support logic brings a security hole in the checking function.

The deprecated or banned API should not be used because it may miss a length parameter. Even if you use a safe version of API, you still need to pay much attention to the input parameter, especially the length of the buffer. We have seen bad examples when the project tried to clean up the banned API usage. The developer filled a wrong length parameter to a safe string function, which makes the boundary check in the safe string function useless.

Race Condition

In general, there are two typical race conditions in firmware.

The first one is the race condition for the external data buffer for the check function. This brings a typical time-of-check/time-of-use (TOC/TOU) issue. The right way to handle this type of race condition is as follows: 1) copy the data from an untrusted environment to a trusted environment, 2) verify the data in the trusted environment, and 3) use the data in the trusted environment. The data in the untrusted environment should never be used in steps 2 and 3. One example is the trusted execution environment (TEE) communication buffer. The TEE handler should copy the communication buffer into TEE and then verify and use the data inside of the TEE. Another example is the boot flash content, where a root-of-trust should copy the boot flash to a trusted memory, such as cache, and then verify and use the content in the trusted memory. If the external flash cannot be trusted, then it should not be accessed anymore after verification.

The second one is the race condition for the critical register unlock in the TEE. This is a typical TEE-based protection. The X86 system management mode (SMM)–based flash protection is one example. The flash region is locked, and no flash write is allowed after boot. The flash region can only be unlocked inside of SMM. The normal process is as follows: 1) enter SMM, 2) unlock the flash region, 3) write flash content, 4) lock the flash region again, and 5) exit SMM. These five steps must be in one system management interrupt (SMI). Before the CPU performs the unlock action, this CPU must check the state of other CPUs to see if they are also in SMM running trusted code. If there is one CPU not inside of SMM, then this malicious CPU can perform the flash content write after the flash region is unlocked by the CPU in SMM. As such, if we need to unlock the critical register in the TEE, we must check that all CPUs are in the TEE and running trusted code.

Hardware Input

Hardware input is an extension for the external input class of concern. We list it here independently because it is a new threat and it is easily ignored when we design a solution.

The device-specific data is the hardware input, such as the USB descriptor or Bluetooth Low Energy (BLE) advertisement data. The attacker can easily create malicious data and send the malformed data, such as the USB FaceDancer tool. At the same time, we have seen some implementations just follow the specification and assume that the device sends the data according to the specification. Eventually, the malformed data caused a buffer overflow. The same attack can be on the Serial Peripheral Interface (SPI) bus, Inter-Integrated Circuit (I2C) bus, System Management Bus (SMBus), and so on.

The silicon register is another hardware input because the attacker may program it to a malicious state and attack the TEE. The remap register reprogramming and the memory mapped I/O (MMIO) base address register (BAR) overlapping are two common techniques in the address alias attack. As such, if possible, we should lock the configured silicon register. For the unlockable MMIO BAR register, an overlap check is always required before accessing any data in the MMIO region. The overlap check should cover the TEE, such as SMM, the high-privilege environment such as the hypervisor, or any other high-privilege assets to potentially overlap the MMIO region.

DMA attacks have become more and more popular. The PCI Leech is a tool to generate DMA from a PCI device to attack the system. It could run in both the OS phase and the pre-OS firmware phase. If a DMA attack is included in the threat model, then DMA protection should be included. The time to enable DMA protection should also depend upon the threat model. If only external DMA threats need to be considered, the DMA protection can be enabled before we connect the external device. If the internal DMA threat needs to also be considered, the DMA protection should be enabled before the DRAM initialization. If the internal DMA can access the SRAM, then the DMA protection should be enabled by default when the system powers on.

Secret Handling

If the firmware needs to deal with a secret, such as a password, then the best practices for secret handling must be followed. A common mistake is that the secret is left in the memory, such as the key buffer, temporary local variable to convert the format of the secret from ASCII to Unicode or vice versa, or communication buffer to pass the secret from one environment to the other environment. The secret should be cleared after use in all those places.

When clearing the secret, please pay attention to the compiler optimization. The zeroing memory function might be optimized by the compiler. Please always double-check the final generated binary to confirm the zeroing action is still there.

If the secret needs to be stored in the non-volatile memory, then we should not use plain text. The best practice is to use a slow hash function with salt data. Please pay attention to the special data management attribute of the non-volatile memory because the removal operation might simply be a flag setting on the volatile memory storage to achieve the best performance. One example is the file system. Even after a file is deleted, the content of the file is still on the disk. Saving the secret in such a file system is not a good idea, even as temporary storage.

Register Lock

After the system boots, the firmware should lock down the configuration as much as possible. The most important ones include the flash region lock, the TEE lock such as SMM, and system configuration lock, such as MMIO BAR. A simple check you can do is to read the datasheet to see if there is a lock register. If there is, then probably you need to lock it, unless you are told not to lock with a good justification.

Care must be taken that the lock action might not be a register setting. It might be a command, such as the End Of Post (EOP) command transmitted as an Intel Management Engine (ME) EOP message; a freeze command, such as the ATA SECURITY_FREEZE_LOCK command; or a block command, such as the TCG OPAL BLOCK_SID command.

Secure Configuration

In firmware, some security features are configurable, for example, the secure boot and TPM capability. The configuration can be static or dynamic. For the static configuration, it should be locked by the firmware to prevent any malicious reconfiguration, such as the flash lock, TEE lock, or MMIO BAR lock. For the dynamic configuration, the platform should use an access control mechanism to prevent the malicious configuration, such as the secure boot policy change requiring the authenticated variable update and the TPM configuration change requiring physical user presence.

An attacker may enable the recovery mode or manufacturing mode to bypass some security checks. We should design the solution carefully to apply the same security policy in the special boot modes. For example, skipping the secure boot verification in manufacturing mode is probably not a good idea.

A production implementation should not include any debug-related code or data. A debug message may cause an information leak in the TEE. A debug service handler may expose an unnecessary attack surface. A debug key or test key in the production platform may lead to a bypass of the authentication via a debug tool. All of those should be removed in final production.

An attacker may attach a debugger to the product in order to steal information in order to tamper with the system. The telemetry information is allowed for sending to the debugger, but the private key should never be exposed. Also, a root-of-trust module should detect this behavior and report a different firmware measurement to distinguish a debugger-attached boot from a normal boot. As such, the verifier can know the system is under debug and assert a different trust level.

In the TCG trusted boot solution, the completeness is the most important thing. The firmware must measure all required data into the right Trusted Platform Module (TPM) Platform Configuration Register (PCR). If a firmware forgets to measure one component, the tampering of this component will not be discovered. People have demonstrated how to use this missing measurement in tboot to attack the Intel Trusted Execution Technology (TXT) in S3 resume phase.

S3 resume is another perfect attack point because the system needs to be reconfigured in the S3 phase. All the secure configuration policy in the normal boot should be applied to S3 resume as well.

Replay/Rollback

The firmware usually needs to be updated. One threat in the firmware update is that the attacker may roll back the current firmware to an old known vulnerable version. As such, the version check in the firmware update is as important as the firmware integrity check, such as digital signature. The firmware version must be signed as part of the firmware image. The new firmware image version must not be smaller than the lowest supported version number (LSN) of the current firmware image.

If the firmware supports a data communication protocol, then the old vulnerable communication protocol must be excluded in the implementation. Otherwise, the attacker may try to negotiate with the firmware and downgrade the communication protocol to the older vulnerable one. The SSL Padding Oracle on Downgraded Legacy Encryption (POODLE) attack is such an example. It downgrades the TLS to SSL3.0.

Another example is the Qualcomm Achilles vulnerability. When a Digital Signal Processor (DSP) chip loads a library, the signature of the library is verified. However, there is no version check in the loader of the DSP and there is no device limitation. The attacker may find an old known vulnerable signed library from an old device and load it on a new DSP device. This is a typical downgrade vulnerability.

Cryptography

As such, if the hardware provides the random seed or random number, we should use the hardware-generated one.

The developer should also be aware of the randomness requirement in different algorithms and protocols, such as initialization vector, nonce, counter, sequence number, and so on. The initialization vector must be uniformly random. Using a fixed value for the initialization vector is a bad idea. A sequence number might not need to be random, but an incremental value needs to be synchronized between the sender and the receiver.

Similar to secret handling, the symmetric key and the private key must be cleared after use.