Meltdown and Specter reveal original hardware and software design flaws that have existed for decades. This article describes both attack scenarios, introduces an alternative to Meltdown immune kernel technology, and shows a system development approach that mitigates Specter attacks.
The hardest hit by Meltdown and Specter are managers of sensitive data, including IIoT, government, medical, automotive, and other critical systems and platforms providers. The designers of these complex software systems are now fighting for bug fixes through a mix of compiler updates, kernel patches, and CPU microcode patches.
Patches have proven to be inadequate because they only partially mitigate the underlying problem and, as many have noted, destabilize existing systems at both the software and hardware levels. For many, this is a rude awakening, not so much because of the loss of supposedly supposed security, but rather because of the realization that in many cases security altogether is completely absent. How can developers, in the face of Meltdown and Specter, continue to meet the requirements of Safety and Security, and how can the desired Internet-of-Trust be created?
Meltdown and Specter are questioning the validity of many years of software and hardware designs. But they also provide insight into how systems can be defended against these attacks. Detecting problems enable appropriate solutions because not all systems were vulnerable to attacks. Some systems were protected – and required no patches, reconfigurations, recompilations, or redesigns.
What distinguished this resilient, sustainable system infrastructure from others was a unique separation kernel technology, based on the work of John Rushby, the inventor of the Separation Kernel. It enables system developers to separate critical computing environments with improved hardware control.
Separation and the “meltdown litmus test”
Separation is a fundamental concept in functional and data security and has been used in high-assurance system designs for decades. Regarding functional safety, the partitioning of air traffic systems (DO-178C, CAST 32, Integrated Modular Avionics) relies on the separation of components to ensure their protection. As far as data security is concerned, divorce is the backbone of the strictest standards: US Department of Defense MILS, for example, are implementations of security models based on the principles of separation and controlled information flow. Within these contexts, separation errors almost inevitably lead to safety deficiencies.
Keep separation, restore trust
Although the attack scenarios differ in important characteristics, both Meltdown and Specter are so-called side-channel attacks. The attacker uses an advanced, subversive method (cache timing analysis) to examine the state of the cache while deriving the values of the temporary referenced kernel memory. While each variant exploits a different design flaw, both scenarios are undeniably capable of bypassing the security controls of legacy operating systems and hypervisors – without the need for administrative access or infiltration of the privileged code base. If an attacker gains administrative access through these types of side-channel techniques, he will be able to take over the entire system.
Meltdown and Specter have been identified as hardware-inherent processor design issues. As a result, software developers may mistakenly believe they can not do anything to protect the designs of their high-assurance systems. By properly implementing proven high assurance principles, you can adequately protect critical system assets from meltdown and significantly mitigate Specter’s negative impact. Also, vulnerable systems are often designed to be resistant without redesign.
Meltdown in detail
In Meltdown, an unprivileged attacker can extract all the physical memory of an operating system or hypervisor at approximately 100 to 500 KB / s. This is possible by exploiting a common CPU performance feature, Out-of-Order Execution (OoOE). This exploits addressed two kernel design options: general access to system memory and combined user and kernel space storage management.
Almost all OS/hypervisor kernel designs rely on software performance optimization methods that store both virtual user process address translations and kernel address translations in the same lookup tables, so that the kernel can quickly transfer data to and from application storage, and so on benefits from address conversion caching. Figure 1 shows the translation of virtual to physical addresses of user applications and the conventional recordings of the hypervisor / OS kernel to the system memory combined in the same table entry per application.
Meltdown studies have shown that OoOE resets the permission resolution between user or kernel address lookups, which allows user applications to directly access virtual kernel addresses in their program to allocate “illegally” referenced memory in the CPU cache load. The CPU ultimately issues a memory access exception error for the attacker’s memory reference to kernel addresses but does not restore the state of the cache. The attacker then uses a cache timing analysis to examine the state of the cache, deriving the values of the temporarily referenced kernel memory.
Solution for meltdown
The simple solution to meltdown is page table isolation and least-privilege memory access. Both methods have been integrated with the Lynx Secure Separation kernel since its introduction. In Lynx-Secure, all kernel-to-physical addresses are stored in a different page table rather than in application/guest OS page tables.
Lynx-Secure is a high-assurance virtualization technology based on robust design principles. As an alternative to traditional centralized resource and service-oriented designs found on most operating systems and hypervisors, the technology is deeply rooted in the least privilege design from both a kernel design and user model perspective. It enforces a decentralized design approach where each guest computing environment is independent of locally managed resources.
The autonomy of each guest environment prevents the kernel from having to provide global services, which undermines the execution of Meltdown. Figure 2 shows Lynx-Secure’s virtual storage management scheme, where the kernel has its page table and space for minimal use only.
Examination of Specter
Specter allows an attacker to read unauthorized memory from an application address space and across address space, including OS/hypervisor kernel memory. Unlike Meltdown, Specter uses CPU branch prediction as a mechanism to search temporary code paths to access protected storage. The attacker can not access the memory directly but later derives it from the cache timing analysis.
Branch prediction is a CPU performance optimization method that allows the CPU to predict the target value of a control flow operation so that the execution pipeline does not have to wait for the resolution of the target location.
Specter presents a greater assurance challenge than Meltdown and accesses unprivileged storage in the attacker’s CPU cache without using the direct reference to the victim’s memory in the attacker code. Specter targets code patterns that contain conditional paths that can lead to unauthorized memory access. There are two different ways to exploit Branch Prediction: bypassing length checks and manipulating the jump address cache (Figure 3).
Bypassing length checks
The length check bypass is an attack on the victim’s code that accesses large indexes beyond the index boundary of memory arrays. By training the branch predictor with successive calls to the function using “legal” (non-temporary) index values, the attacker causes the CPU to speculatively assume that it is sure to jump to the array lookup code on the subsequent function call.
Once the Branch Predictor is trained in this manner, the attacker can start this function call with each index value, knowing that the CPU will temporarily / transiently load the memory contents after the attack-driven indices into the cache.
Manipulate jump address buffer
Branch Target Buffer manipulation uses branch instructions to jump to variable destination addresses that contain code (called gadgets) that accesses private memory within the destination’s address space. By “training” the CPU’s branch predictor, the attacker can jump to gadgets that would normally be inaccessible.
In the face of Specter, system developers must ask themselves whether their system still guarantees the confidentiality of sensitive data. How does a system developer of a service-oriented, therefore centralized architecture know if standard processes such as user login and data encryption do not disclose secretly such as authentication and decryption passwords? Figure 4 shows possible attack vectors on a traditional centralized resource and service-oriented architecture.
Protection from Specter
Side-channel attacks generally measure the victim’s code activity, which accesses a common computer system. In traditional centralized resource and service-oriented designs, each application depends on a single kernel to terminate the execution of threads, manage resources, and provide data (see Figure 4). Here, the task of preventing an attacker from accessing the kernel-aware system internals is almost intractable. Even worse, if applications have the option of dynamically gaining administrative access to the OS/hypervisor from scratch, Specter-like attacks can increase dramatically.
Least privilege principle
The Lynx-Secure separation kernel raises the least privilege architecture to a stringent level. It eliminates the central resource managers, data services, and administrative user control rights. The kernel design still allows applications to run unmodified in guest environments. The difference with other solutions is that critical code responsible for initializing the hardware and handling hardware exceptions has been separated from the code that supports the application services (memory manager, device driver, privacy). Also, each application support layer is autonomously segmented. By decoupling the application support layers from the vital hardware control functions and ensuring
Distributed system architecture
Software designs with centralized service functions such as data protection are indispensable. With the least privilege principle as a foundation, a critical security service can be decoupled from the kernel so that it is only exposed to the applications it needs to know. Nevertheless, this service must be stable and resistant to side channel attacks.
Lynx-Secure provides fine-grained system configuration control, which eliminates the possibility of guests/applications accessing sensitive information – including explicit assignment of guests to CPU cores, memory addressing control, and read-write assignment of all CPUs. Addressable resources. By ensuring that something secret is executed using CPU resources utterly independent of a user process, malware cannot find anything secret.
For systems that do not have sufficient resources to allocate critical functionality, greater attention needs to be paid to software design. Specter thrives in software designs with a tight coupling between the malicious application and the victim’s code. Traditional OS / Hypervisor System APIs are preferred targets for Specter attacks, as the attacker can lodge in victim’s interfaces and directly invoke the victim’s target code. Alternatively, the distributed Lynx-Secure system architecture separates applications and services. Applications can not simply call services directly but must make a service request and store data for these services through message APIs. This allows a higher degree of separation between attack and victim code.