icon / menu / white V2Created with Sketch.
Switch LanguageSwitch Language
Hardware Vulnerabilities: Taking Precautions and Still Being Attacked

Hardware Vulnerabilities: Taking Precautions and Still Being Attacked

In the first week of 2018, Meltdown and Spectre were publicly disclosed. The news of these vulnerabilities led to shockwaves across the world, with consumers and businesses terrified about their security posture and potential to be compromised.

To understand why these vulnerabilities were such a problem, we need to understand what makes them unique. Although there are hundreds of new vulnerabilities reported every day, the vast majority of them are in the software. This includes the operating system (such as Windows 10, macOS, android, or iOS) or the web browser you are using (such as Chrome or Mozilla).

When a software vulnerability is disclosed, developers can debug and diagnose what is causing the aberrant behaviour, fix the code that caused the vulnerability in the first place, and finally, release the patched version of the software to make it available immediately to everyone in the world.

Meltdown and Spectre, however, are hardware vulnerabilities. More specifically, these vulnerabilities are due to issues with the design choices and features of the hardware (in this case, the CPU chip). Depending on the vulnerability in question, proper safeguards on the software level might even be circumvented. This means that it may not be possible to “patch” the CPU at all; the only way to ensure security might be to buy a completely new CPU!

Although Meltdown and Spectre are sometimes considered a single vulnerability, it is more correct to think of them as a family of vulnerabilities that depend on specific features of modern CPUs. Meltdown relies on a feature called “out-of-order execution”. This feature allows an unprivileged user process to read the private memory of a different process, such as other applications of the kernel of the OS itself. This private memory may contain secrets or passwords.

Spectre, on the other hand, relies on speculative execution. Spectre works by allowing an unprivileged user to leak the memory of a different process, even if the process in question is perfectly written without any bugs and follows best practices. In fact, a well written program is MORE susceptible to Spectre-type vulnerabilities because best practices means more safety and error checking! Both of these are examples of side-channel attacks. A side-channel attack is one that relies on information inferred about the data in a computer based on its implementation, and indirectly-related signals such computation timing, cache monitoring, and power monitoring.

While Spectre and Meltdown may be the most famous examples of hardware vulnerabilities, they are far from the only ones. Throwhammer and RAMBleed, for example, are vulnerabilities that take advantage of how memory (SDRAM) chips are manufactured. They belong to a family of vulnerabilities known as Rowhammer attacks. These are caused by a hardware design flaw in the chip. Normally, a memory chip is made up of memory cells arranged in a grid pattern. These cells store the value of a single bit (0/1). A high voltage corresponds to a 1 and a low voltage corresponds to a 0. In 2014, researchers found that if the same row of cells were repeatedly read over and over again, an electrical charge will be created that flips the bits in the adjacent rows. This means that theoretically, it is possible to use this attack to modify the data of other processes i.e. either corrupt or manipulate data.

Throwhammer is a vulnerability that allows rowhammer attacks to be carried out over a network due to the Remote Direct Memory Access (RDMA) feature of server-grade network cards. RAMBleed is a variant that combines Rowhammer with a side-channel attack to make it possible to steal data from adjacent memory cell rows, rather than just modifying it.

When a vulnerable design choice or feature is discovered, the offending feature is investigated more thoroughly by security researchers, and more variant vulnerabilities are usually discovered over time. Meltdown, for example, has at least 6 variants, while Spectre has at least 9. This time lag can result in negative PR for the companies involved. Furthermore, the research into Meltdown and Spectre eventually led to the discovery and categorisation of “Microarchitectural Data Sampling (MDS) attacks” after finding two new families of vulnerabilities: Fallout and RIDL.

These are similar to Meltdown/Spectre in that they are side-channel attacks and can be used to leak passwords and secrets. They take advantage of MDS to expose data leaving internal CPU buffers, which can include non-cached data. While Meltdown and Spectre depend on knowing which CPU chipset is used by the machine to successfully exploit the vulnerability, Fallout and RIDL does not require such information. This makes it much harder to mitigate these vulnerabilities. The best way to mitigate this vulnerability is to disable hyperthreading on all CPUs, which may result in a noticeable performance drop.

Most vulnerabilities take advantage of a specific application with vulnerable code. Anti-virus tools usually work by comparing the contents of each file with a database of malicious code signatures. If there is a match, that file is considered to be malicious. In contrast, the attacks discussed so far can be abused as part of any piece of software that runs on a machine, not necessarily a malicious, pre-compiled application binary. This makes them extremely hard to be discovered by anti-virus solutions (But it is not impossible). Furthermore, most hardware vulnerabilities do not leave any trace in any log files as it bypasses most of the software layer.

While it may be difficult to prevent this kind of attack being possible, they are quite difficult to pull off in practice. This is because they usually require local code execution to be possible. Also, it may take a combination of vulnerabilities to steal actionable data; a single vulnerability by itself may not be able to accomplish much. These attacks are also usually very slow, and thus require a prolonged period of exposure to allow an attacker to steal/corrupt data. Meltdown, for example, can only read memory at ~120 KB/s.

Mitigating hardware vulnerabilities can be troublesome due to the lack of one-size-fits-all solutions. Depending on the hardware, the vendor, and the variant of the vulnerability, the mitigations will be different. This makes it very difficult to know if you are affected without doing some research. Furthermore, when a new family of vulnerabilities is discovered, mitigation might mean sacrificing performance (or money if you need to replace hardware).

Although mitigation is tough, it is not impossible. It starts with having thorough knowledge of all your hardware assets. This allows us to check if there is a new security advisory or a patch available. By looking at what data is most critical and sensitive, we can add layers of security and monitoring controls to protect that data i.e. practicing defence-in-depth. This may make it uneconomical for you to be targeted.

Defence-in-depth allows the defender more time to determine who the attacker is. In cases where resources are not a concern for the attacker, it may not be possible to stop the attacker. However, the extra time may allow you to determine who the attacker is. When a new vulnerability is discovered, the most important thing is to mitigate immediately. Most software vendors will quickly release instructions on how to do this.

Additionally, as most hardware vulnerabilities require local execution, it is extremely important to have good physical security. Do not leave your computer/phone anywhere public as it can be easily tampered with. Do not leave your devices turned on and idle for extended periods of time, as most of these attacks are quite slow. Hardware vulnerabilities are a very thorny problem that will only get worse as computers, phones, and IoT devices become increasingly ubiquitous. Vigilance and a proactive approach are the best tools in this fight.

Related articles

Cutting the theatrics, keeping the security
13 mins
Developer toolbox
Cutting the theatrics, keeping the security
Learn how to calculate CO2 emissions across multiple clouds on a unified platform
5 mins
Developer toolbox
Learn how to calculate CO2 emissions across multiple clouds on a unified platform
A guide to measuring and reducing your Carbon Footprint on AWS
3 mins
Developer toolbox
A guide to measuring and reducing your Carbon Footprint on AWS

Button / CloseCreated with Sketch.