Bottom Line Up Front
Security Researchers have publicly disclosed the details of CPU design flaws that are the result of design decisions made industry wide more than a decade ago to speed up processing and allow a computer’s processor to access information before it was needed.
The resultant vulnerabilities, Meltdown and Spectre both exist outside the Operating System. While Meltdown only applies to Intel chips, Spectre can be executed on Intel, AMD, and ARM microprocessors (which cover just about every mainstream, modern computing device out there).
These vulnerabilities are most troublesome for businesses, especially providers of cloud infrastructure which allow many tenants to share processing space on a single platform (i.e. hypervisor), as these attacks involve violating the boundaries between memory (and the sensitive data therein) stored at different permission levels within a system’s memory.
A Brief Explanation of What Happened
Meltdown and Spectre use different techniques to achieve the same end goal, which is to leak sensitive information from a restricted zone to a non-restricted zone within computer memory. Once leaked, that information can then be recompiled and searched for things like user names and passwords or other sensitive information.
Computers are designed to segregate different resources into “protection rings”, which range from Ring 0 (Kernel/processor level) to Ring 3 (User Mode/Applications). The intent of this design was to protect data and functionality from faults and malicious activity, despite all the processing in a computer needing to take place on the same processor and being stored within the same memory.
This same idea is also used in cloud computing and is fundamental to segregating the data and processing of different tenants/users sharing a single cloud infrastructure where many entities share a single pool of computing resources, but are not permitted to access the contents of each other’s respective systems.
The security researchers behind Meltdown and Spectre found a few clever ways to perform “side channel attacks”, which allow them to siphon the data from more privileged zones in memory (i.e. Ring 0) and collect that data within an array (a collection of data in memory) located at a less privileged zone (i.e. Ring 3).
Remember that a side channel attack is an attack based on observations of the physical implementation of a system, or in this case, an attack on the normal operation of the CPU. This equates to a weakness in the design and operation of CPUs. This is opposed to other popular types of attacks such as brute force or social engineering which involve either guessing and tricking one’s way to an end goal.
What Should I Do to Mitigate the Risk?
Risk mitigation is practically the same as it is with all new vulnerabilities. Be sure you have automatic updates enabled on your personal systems and manually apply security patches when need be on your personal systems. Within the organization, be sure that you have an effective security patch management program in place.
Patches for Meltdown, which is the more severe of the two vulnerabilities, are already being released. Spectre appears to be a more difficult-to-execute vulnerability, but is also a harder issue to resolve and will be a vulnerability that we have to contend with for a while.
This threat is most applicable to cloud hosting providers, since the security implications are greatest for organizations leveraging shared cloud infrastructure (e.g. AWS, Azure and so on). For users of less mainstream cloud infrastructure, such as co-lo facilities that have implemented makeshift “cloud” platforms, it is imperative that organizations perform their due diligence and manage their vendors accordingly.
Do not assume a vendor is doing the right thing. Exercise your right to audit if need be and insist on evidence that key vendors are performing the necessary steps to ensure the confidentiality, integrity and availability of your organization’s key data.
Further Reading and Assistance
Links to the security research papers detailing the intricacies of both vulnerabilities can be found below. If you need help with making sure your organization is doing all it can to mitigate the risks of these vulnerabilities or any other, you can leave us a comment below or contact us here.
Leave A Comment