Meltdown & Spectre: Diseases in need of immunization
February 05, 2018
Story
To guard against hardware and software vulnerabilities that have yet to be detected, as well as attacks that have yet to be written, it is imperative to secure the entire chain of vulnerability.
Cybersecurity is very much like modern medicine that attempts to prevent infectious diseases before they strike. When prevention fails, healthcare professionals urgently treat and try to isolate illnesses so they don’t spread epidemically across increasingly distributed populations.
Security experts warn that for flaws like Meltdown, Spectre, and other known and unknown vulnerabilities, the worst is actually yet to come because of the billions of embedded endpoint CPUs that form the backbone of the IoT (Sidebar 1). These connected edge devices – including connected and autonomous cars, consumer goods, smart meters, industrial control systems, security cameras, and countless more – will inevitably be vulnerable to attacks unless a truly robust, end-to-end solution is quickly and widely adopted on an industry-wide basis.
A breakdown of the Spectre and Meltdown variants
By Jamie Leland, Content Assistant
The Spectre and Meltdown vulnerabilities were originally discovered by Jann Horn, a 22-year-old white hat hacker working for Google’s Project Zero security research team in Zurich, Switzerland. Horn identified three flaws in the CPU architectures of numerous Intel, Arm, and AMD processors, which he simply labeled Variant 1, Variant 2, and Variant 3. Each of these takes advantage of CPU data cache timing to leak information from virtual memory across local security boundaries during processor execution.
Variant 1 (Spectre): Bounds check bypass
In many modern processors, branch prediction is used to reduce memory latency during program execution. In doing so, the processor speculatively loads uncached data prior to branch execution, which is classified as an out-of-bounds read. Normally this does not matter because the processor rolls back to a non-speculative execution state once the branch has executed so that the speculative instructions do not affect registers or other operations.
However, Variant 1 reveals that when various arrays are uncached and all other accessed data is cached in certain branch prediction code patterns, a hacker could use this out-of-bounds check bypass to compare the time required to load data located in L1 cache during speculative and non-speculative execution states. This information can then be used to determine whether the value of that data is a 0 or a 1.
Variant 2 (Spectre): Branch target injection
Variant 2 reveals that it is possible for different sets of code operating in different security contexts to influence each other’s branch prediction, which an attacker could leverage to redirect execution code and leak data into cache.
For example, after identifying code containing an indirect branch with a target address located in memory, an attacker could flush the cache line containing that address out to main memory. When executing, the processor will therefore have to load the complete cache in order to calculate the true destination address of the branch. During this time, which typically consumes a few hundred clock cycles, the CPU will continue to execute speculative instructions based on branch prediction. Operations that occur in this window can be reverse engineered to leak data into the cache.
Variant 3 (Meltdown): Rogue data cache load
Variant 3 attempts to read kernel memory from userspace by exploiting permissions checks for address access that could have a significant impact on CPU performance. In cases where an address might not be on the critical path for reading data from memory to a register, memory could provide the results of a memory read to ensuing instructions immediately and perform asynchronous permissions checks later to maintain performance. A flag in the reorder buffer will raise an exception if the asynchronous permissions check fails, but an attacker can widen this window using a high-latency mis-predicted branch.
Further details on the Spectre and Meltdown vulnerabilities can be found on the Project Zero blog at https://googleprojectzero.blogspot.com.
So far, the treatment for both CPU-level security flaws and software-persistent vulnerabilities has come in the form of updating mechanisms, including galvanic and firmware over-the-air (FOTA) patches, but these have limited efficacy against current and future breaches. What is needed is a preventative approach – an immunization – to protect firmware, memory, and the cloud from malicious code and external hacking. To fully guard against hardware and software vulnerabilities that have yet to be detected, as well as attacks that have yet to be written, it is imperative to secure the entire chain of vulnerability – from deeply embedded endpoints, out to the cloud, and up into the enterprise management layer.
- Edge – IoT edge devices have varying (and sometimes limited) resources – such as energy and latency concerns. Security solutions need to accommodate these variables and be processor- and OS-agnostic. The “holy grail” of protection is to prevent overwriting, modification, manipulation, erasure, and ransomware attacks on firmware in all connected and IoT devices.
- Network – FOTA updates make edge devices extremely vulnerable. Chip vendors should consider embedding hardware in the microprocessors themselves to inoculate them from malicious software interference, while guaranteeing the preservation of system memory contents. By fully securing IoT devices during FOTA and out to the cloud, users can maintain control and analyze threats and attacks in real time.
- Cloud – Protecting, defending, and managing the firmware in an embedded system is a unique and effective way to immunize IoT edge devices. Enterprise management systems can be used as an extra layer of security, allowing companies to treat new “diseases” as they develop down the road.
Spectre and Meltdown quarantine
It is absolutely unavoidable that new security flaws will be uncovered, and that hackers will continue to find ways to exploit vulnerabilities. But with a creative and comprehensive approach to protecting IoT edge devices, we can eradicate the Meltdown and Spectre epidemics and guard against other outbreaks that will inevitably follow.
Erez Kreiner is the co-founder of NanoLock Security and the former head of Israel’s Cyber Security Authority. He is also an associate at the International Institute for Counter-Terrorism (ICT) and a lecturer at a number of academic institutions.
