Risks and Vulnerabilities in Hardware Systems: A Case for Greater Awareness

Introduction

As the ongoing battle between security measures and cyber attacks continues, the use of hardware-based methods for achieving various nefarious objectives or villainous objectives will become increasingly important for both attackers and those working to defend against them. Despite their potential to cause significant damage, many organisations still undervalue the importance of securing their hardware components. In this article, I will make the case for why hardware-based attacks should be taken more seriously and given higher priority in our ongoing efforts to secure any systems.

Towards the end of this article, I will be presenting my research on a specific type of hardware-based attack vector. The goal of my investigation was to explore the hardware surface and gather insights for this article. My research focused on examining the ability of a malicious hardware device to execute remote code on the Linux kernel. For those interested in learning more about the vulnerabilities mapped in this research, feel free to skip ahead to that section.

What Are Hardware-Based Attacks?

When discussing the realm of security threats, it’s important to consider not just software vulnerabilities, but also the potential dangers posed by hardware. A hardware-based vector refers to a method of attack in which the attacker utilizes some sort of physical hardware in order to gain some asset or capability. This could include exploiting firmware vulnerabilities, exploiting hardware logic, or physically tampering with a device. On the other hand, the hardware attack surface refers to the total area of exposure of a system or network to these types of attacks: the sum of all potential points of vulnerability or entry points that an attacker could utilize.

When considering the potential for attack, the hardware attack surface offers just as much opportunity for creativity as any software-based vector. Many existing examples can be found that force us to consider this, for example the mind-blowing findings Meltdown, Spectre or Rowhammer.

Moreover, actual attacks found in the wild, such as the SuperMicro motherboards backdoor, demonstrate the real-world dangers of hardware-based attacks. Additionally, the leaked NSA ANT catalog showcases numerous examples, including my favorite RAGEMASTER attack that utilized a VGA cable to leak a victim’s screen.

Uncovering the Risks of Hardware-Based Attacks

The idea of hardware-based attacks may seem less cost effective, but it is important to understand that the distinction between hardware and software is becoming increasingly blurred. Programmable hardware, firmware, microcontrollers, buses, and other technology all involve a combination of hardware and software, which can lead to a variety of issues and security concerns.

Hardware as a Valuable Target for Attackers

Hardware serves as the foundation of all software and holds the potential to access vital software assets such as access to the Linux kernel as discussed in this article. However, hardware also holds other types of assets or capabilities such as cryptographic keys or network/bus access, making it a valuable target for attackers.

For example, physical layer cable managers, like Ethernet MACs or USB controllers, may contain vulnerabilities or backdoors that allow an attacker to send messages between Ethernet ports, circumventing routing and firewalls.

Logical Vulnerabilities in Hardware Systems

Hardware systems include complex logic designed and implemented by humans. As with any product of human logic, hardware systems can also be vulnerable to attack and manipulation. Attackers may exploit vulnerabilities in the hardware’s design or implementation.

Field-Programmable Gate Arrays (FPGAs) are a good example of hardware that includes a large amount of human logic (VHDL, Verilog are actually source code languages). Because FPGAs are often used in critical infrastructure and industrial control systems, they can be a prime target for attackers. The fact that the logic in FPGAs is mostly closed-source and rarely reviewed with security in mind may make them particularly vulnerable. Attackers may be able to exploit vulnerabilities in the FPGA’s logic or firmware, potentially gaining unauthorized access to sensitive information or resources. This highlights the importance of including security considerations in the design and implementation of programmable logic in hardware systems, including FPGAs.

I will save the discussion about vulnerabilities in hardware logic and what their limitations are for another time, but just to give you an idea, take integer overflow class of vulnerabilities for example.

Integer Overflow: Example of Hardware Logic Vulnerability

Integer overflow occurs when a calculation produces a result that is too large to be represented within the available number of bits.

The customization of hardware registers, compared to software variables, can make it more susceptible to this type of vulnerability.

A piece of logic in software requires a number between 0–3, a char data type with 8 bits would typically be used (which is really stored in a larger register in most cases). In hardware, however, a 2-bit register can be chosen to store the same information, but this smaller size can increase the risk of integer overflow errors.

Risks in Physical Supply Chains

Another rather classic issue in the realm of hardware security is the vulnerability of the physical supply chain. Ensuring that all the “bits and pieces” needed to create a hardware system are not being tampered with or influenced by malicious actors can be a challenging task.

Digital Components in Hardware Supply Chains

Additionally, there are many specifications, BOM (bill of materials), layouts, netlists, firmware and other digital components that are also transported along a software based supply chain, introducing potential risk at each connection. More so, unlike the closed-source nature of most hardware firmware, software supply chains are often intertwined with open-source. For example, while a specific network card firmware may be closed-source, the collaboration, packaging, testing and transportation frameworks are likely to be open-source, creating an additional layer of potential vectors.

Reality Check

In security theory, all attack and defense methods are considered fair game, but in reality, there are also many drawbacks to many areas of the spectrum. For example, dynamic execution flow, physical access, and cost-effectiveness can cause malicious parties to focus on software options before exploring hardware options. Additionally, the nature of hardware design and testing and synthesizing flows reduce the range of exposure and human errors.

In my opinion, state-level players are often the only ones who view the hardware attack surface as a viable target for both attack and defense, partly due to the unique benefits that hardware attacks can offer, such as low detectability, stability, and a longer lifespan.

Vulnerabilities

During a casual review of the current kernel vanilla sources, I came across several zero-day vulnerabilities in random drivers. Although these vulnerabilities may not pose a significant threat due to their lack of exploitability or potential reward, they still serve as a warning sign that there could be deeper and more severe vulnerabilities hiding beneath the surface. For a malicious attacker, it only takes one successful vector to make their efforts worth it.

All vulnerabilities were disclosed to the Linux kernel security team just in case they are interested; understandably, they responded that they currently do not really include malicious hardware in their threat model.

AMD Display Core Vulnerability

Let’s imagine some attacker simply going around stock exchanges buying then returning some compromised HDMI cables. At some point someone is going to plug one of these cables into a high asset machine.

Vulnerability was discovered in the Linux kernel AMD display port driver. The vulnerability is triggered when the driver tries to test its audio channel, and can be exploited by a malicious monitor or cable. The exploit works by providing a malicious size in one of the channel registers, which causes a buffer overflow.

The vulnerability was reported to the maintainers and has since been patched (see patch commit).

Details:

enum dpcd_audio_channels {
AUDIO_CHANNELS_1 = 0,/* direct HW translation */
AUDIO_CHANNELS_2,
AUDIO_CHANNELS_3,
AUDIO_CHANNELS_4,
AUDIO_CHANNELS_5,
AUDIO_CHANNELS_6,
AUDIO_CHANNELS_7,
AUDIO_CHANNELS_8,
AUDIO_CHANNELS_COUNT
};
/*
* Global array of audio test pattern period dpcd_pattern_period,
* which has a size of AUDIO_CHANNELS_COUNT (9 channels)
*/
union audio_test_pattern_period dpcd_pattern_period[AUDIO_CHANNELS_COUNT] = {0};
union audio_test_mode {
struct {
unsigned char sampling_rate :4;
unsigned char channel_count :4;
} bits;
unsigned char raw;
};
/*
* For loop that read up to 16 bytes from device in to the 9 byte array.
*/
for (channel = 0; channel < channel_count; channel++) {
core_link_read_dpcd(
link,
DP_TEST_AUDIO_PERIOD_CH1 + channel,
&dpcd_pattern_period[channel].raw,
sizeof(dpcd_pattern_period[channel]));
}

The driver sets the buffer size to 9 channels, while the display port can actually set 16, which leads to overwriting the pattern buffer.

Status: Reported and fixed.
Affected commits: Until 3dfe85fa87b2a26bdbd292b66653bba065cf9941.
Exploitability: Not deemed exploitable as the overflow does not affect any important field.
Code: https://github.com/torvalds/linux/blob/6e93d5b0333279d8968a2972065f47a899fb58b9/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c#L4452
Patch commit: https://github.com/torvalds/linux/commit/3dfe85fa87b2a26bdbd292b66653bba065cf9941

TOSHIBA TC358743 HDMI to MIPI Bridge Driver Vulnerability

Vulnerability was discovered in the Linux kernel TC358743 HDMI to MIPI bridge driver, most commonly found in Raspberry Pi systems. The vulnerability is triggered when the driver tries to read the Consumer Electronics Control (CEC) registers from the bridge device and can be exploited by a malicious bridge device. The exploit works by providing a malicious size in one of the CEC registers, which causes a buffer overflow.

Consumer Electronics Control (CEC) is a feature of HDMI designed to control HDMI connected devices by using only one remote controller.

Details:

#define CEC_MAX_MSG_SIZE 16
…
v = i2c_rd32(sd, CECRCTR);
msg.len = v & 0x1f;
for (i = 0; i < msg.len; i++) {
v = i2c_rd32(sd, CECRBUF1 + i * 4);
msg.msg[i] = v & 0xff;
}

The driver uses a buffer of size 16 bytes while allowing the device to send up to 31 bytes.

Status: Reported to the maintainers.
Affected commits: Current source code includes the issue.
Exploitability: Maybe exploitable, but the device is not very common.
Code: https://github.com/torvalds/linux/blob/40037e4f8b2f7d33b8d266f139bf345962c48d46/drivers/media/i2c/tc358743.c#L966

ST ST95HF NFC Driver Vulnerability

Vulnerability was discovered in the Linux kernel ST ST95HF NFC reader driver. The vulnerability is triggered when the driver tries to communicate with the NFC reader device over the SPI (Serial Peripheral Interface) protocol and can be exploited by a malicious reader device. The exploit works by providing malicious data in one of the messages sent over the SPI, which causes a buffer overflow.

Details:

unsigned char st95hf_response_arr[2];
ret = st95hf_spi_recv_response(&st95context->spicontext,
st95hf_response_arr);
/* Reading from SPI using the first byte from SPI
* Which can be larger than the size of 2 allocated for st95hf_response_arr
*
* Support of long frame
*/
if (receivebuff[0] & 0x60)
len += (((receivebuff[0] & 0x60) >> 5) << 8) | receivebuff[1];
else
len += receivebuff[1];
/* Now make a transfer to read only relevant bytes */
tx_takedata.rx_buf = &receivebuff[2];
tx_takedata.len = len - 2;
spi_message_init(&m);
spi_message_add_tail(&tx_takedata, &m);

Driver sets a buffer of 2 bytes for the input bytes but actually allows the driver to overflow it with any valid SPI message (short or long frame).

Status: Reported to the maintainers.
Affected versions: v4.5-rc1 to current.
Exploitability: Maybe exploitable, but the device is not very common.
Code: https://github.com/torvalds/linux/blame/master/drivers/nfc/st95hf/core.c#L284
Introducing commit: https://github.com/torvalds/linux/commit/cab47333f0f75b685bce1facecb73bf3632e1360

Goldfish Emulated Keyboard Driver

Vulnerability has been discovered in the Linux kernel’s Goldfish emulated keyboard driver, which is used by some Android emulators to provide keyboard functionality. The vulnerability can be triggered when the driver processes an ioctl request and can be exploited by a malicious or compromised application. The exploit works by providing a malicious size or parameter in the ioctl request, causing a buffer overflow.

The driver reads the keyboard map by reading registers mapped to it. The issue can occur when the driver reads a 32-bit length register, allocates the required size, and continues to read the name. If the length is close to the maximum value of an integer, an integer overflow can cause a very small buffer to be allocated, but a very large name to be read into it, resulting in a buffer overflow.

Details:

/* Read the length of the keymap name from a register */
keymapnamelen = __raw_readl(addr + REG_LEN);
/* Allocate memory for the event device structure and the keymap name,
* with a size equal to the size of the structure + keymapnamelen + 1.
* The extra 1 byte is probably for a null terminator.
*/
edev = devm_kzalloc(&pdev->dev,
sizeof(struct event_dev) + keymapnamelen + 1,
GFP_KERNEL);
/* Loop through the keymap name with a length equal to keymapnamelen and
* read each character from the virtual keyboard register
*/
for (i = 0; i < keymapnamelen; i++)
edev->name[i] = __raw_readb(edev->addr + REG_DATA + i);

The vulnerability lies in the fact that keymapnamelen may contain an untrusted value that is controlled by a user-space application. If the value is close to the maximum value of an unsigned integer (UINT_MAX), a signed integer overflow can occur when adding 1 to keymapnamelen. This results in a much smaller buffer being allocated than is needed to store the keymap name. When the name is read into this small buffer, a buffer overflow occurs. This vulnerability could potentially allow a malicious application to execute arbitrary code in the kernel, leading to a system compromise.

Status: Reported to the Android disclosure program.
Affected versions: Current.
Exploitability: Not sure if exploitable, but the emulator’s guest user to guest kernel privilege escalation is probably not very interesting in any case.
Code: https://github.com/torvalds/linux/blob/master/drivers/input/keyboard/goldfish_events.c#L126

Summary

Hardware security is an often overlooked aspect of overall system security, but it is worth giving a second thought, especially in high-value systems when modeling the security and threat model as a defender or attacker. Although the threat commonly may be low, this exercise could uncover weaknesses worth investigating. Don’t neglect the significance of hardware security in ensuring the overall security of your system.