Welcome to 2018! It’s only been a few days into the new year and we already have newly named bugs, thanks to the Google Project Zero, Cyberus Technology, and the Graz University of Technology. Jann Horn, Werner Haas, Thomas Prescher, Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz, Paul Kocher, Daniel Genkin, Mike Hamburg, Moritz Lipp, and Yuval Yarom all contributed to the discovery and disclosure of the Meltdown and/or Spectre. These three teams have identified a flaw in processor design, allowing a low-privilege process to read memory, which could mean anything from breaking ASLR (Address Space Layout Randomization) to recovering passwords from memory. The attacks are made possible by "speculative execution", a technology that allows increased processor speed. There have been some estimates that the latest patches for Meltdown specifically can have anywhere from a five to thirty percent reduction of performance. This estimate appears to be high as most are not reporting substantial impact to system performance. Google additionally has released different techniques that may mitigate the speed reduction even further. The bugs have large implications for attackers, who are already positioned to run code on a compromised machine or within VM environments. Drive-by attacks are also possible, using JavaScript to launch the attack and then read protected memory. The primary concern is the ability to reach protected memory and potentially steal sensitive data such as passwords and other components of sensitivity on the system. Let’s break down the two bugs as they are separate. First, let’s discuss Meltdown. The Meltdown attack is used to read memory written to by the kernel and other user protected memory space. This would allow the attacker to potentially read passwords and other sensitive data. It has been shown to read up to 503 KB/s. In the case of a cloud or virtualized environment, this allows the attacker to read the data from the host system, as well as any other guest VM running on the host. Docker, LXC, and OpenVZ are also affected, since they utilize the host’s CPU. CVE NumberCVE-2017-5754Affected Hardware

• Intel Microprocessors
• ARM and AMD (theoretical, not proven)

Details and Breakdown Meltdown attack is a CPU vulnerability that allows an unprivileged user to read kernel related memory. Since this is a CPU vulnerability, it is independent of the installed OS. As a little background into why the memory is accessible, the kernel maps all the system’s memory into its address space and the kernel is addressed in each user’s space. All OS’s rely on the CPU, guaranteeing the permissions are correct for the virtual address space. The virtual addresses have a bit set to determine permissions for the calling application. The CPU checks the permission bit of the virtual address to determine if the callee has permission to access the requested memory. The vulnerability uses this check to bypass permission restrictions. An exception is generated when a user attempts to access kernel memory. The branch prediction mechanism will attempt to execute the next few instructions until the exception is handled and the out-of-order cache is cleared. In short, the CPU attempts to be more efficient by “predicting” the flow of execution. When the CPU comes to an instruction that is time intensive (say, retrieve a value from disk or handle an exception), it will attempt to process the next few instructions. This is done so that when the slow instructions are finished, the next few instructions can be completed quickly because they are already processed. During the prefetch instruction (out-of-order) operations, the permission bit is not checked. This allows the user to generate an exception, and before that exception can terminate the running process, the out-of-order execution has requested the memory from the kernel space and can store it in micro-operations. These micro-operations are then sent to another process through a covert tunnel. This covert tunnel uses known cache attacks, such as Evict+Time, Prime+Probe, and Flush+Reload. The covert tunnel sends the cache a byte at a time. There are three steps to the Meltdown attack: 1. Cause the Exception - Use out-of-order execution to read kernel memory and write to a micro-operation 2. Exfil Data through Covert Channel - Send the data to another process before exception terminates current process 3. Read from Covert Channel - Scan data for passwords or other interesting data ResourcesOriginal Meltdown Research PaperMeltdown RemediationMicrosoft Client SystemsMicrosoft Server SystemsRedhatVMWareARM Intel has claimed a patch will be available soon and will fix both Meltdown and Spectre: Intel Communication on Meltdown and Spectre Microsoft has also provided PowerShell scripts to validate success after patching. To install, open up the PowerShell (Posh) command prompt and type: Install-Module SpeculationControl   Figure 1 - Before Patching  Figure 2 - After PatchingNext, lets discuss Spectre. The Spectre attack is a CPU vulnerability that allows a process to read data. CPU data can read from the current process, or the kernel using speculative execution and the cache to recover sensitive data from a process by leveraging the branch predictor to train it to know that the branch being used will be true. This allows the process to read private data that would otherwise not be readable. CVE NumbersCVE-2017-5753, CVE-2017-5715Hardware Affected Intel, AMD, and ARM. Details and Breakdown The first step is training the branch predictor to be true. Once the branch predictor is trained, it then invokes the branch with a false value after flushing the cache, then reads from it. If the difference in time from before and after the cache is read is less than the CACHE_HIT_THRESHOLD, then the value saved in the address is from the false speculative execution and it then stores the value. Review of Code The code included in the paper (see Appendix A) shows an example of reading a "secret" value from your process space with the following method. This code has a "victim_function" that checks to make sure that the passed-in value (x) is less than the size of array1, and if it is, then stores the value of array1[x] * 512 into array2, which is 255*512 bytes long. It then trains the branch predictor by calling the function with several calls that train the branch predictor to allow the function to branch to True. The code then calls the function with an invalid offset, which points to the secret data and the training allows the value to be stored in the cache. It then loops over array2, timing the delay while reading the values, and if the delay is less than the max threshold set, it then increments the counter for the results. Possibility of the Attack This one specifically is an arbitrary read, so it can be used to read sensitive memory in the current process, a separate process, or be used as a kernel ASLR defeat. To be able to read memory from another process, it seems you will need some way to have the target process execute a gadget with attacker controlled data. Theoretical Examples

• JavaScript that tries to read passwords in the JIT process space
• Dumping the kernel memory of a host system when running in a VM as root
• Using eBPF filters to bypass kernel ASLR

SourcesOriginal Spectre Research Paper - YAROM, Y., AND FALKNER, K. FLUSH+RELOAD: A high resolution, low noise, L3 cache side-channel attack. In USENIX Security Symposium 2014 (2014), USENIX Association, pp. 719–732 - Project Zero Write-upConclusion Intel, Microsoft, Apple, and all other vendors have stepped up and been able to quickly address the Meltdown vulnerability. The Spectre attacks is going to take a longer-term approach from hardware manufactures, especially if it requires direct firmware patches. These are often difficult patches to deploy corporate wide and one that will take a substantial amount of work in corporations and home users. What individuals should do now is ensure their operating system, browsers, and general patches released by vendors are applied by the affected. The named vulnerabilities come and go and highlight the need to have a strong security program in place with a multi-layered defense strategy. This one was particularly bad as it involved lower level hardware that is the basis for the framework and architecture for operating systems and the foundation of computers. The goods news is that vendors and manufacturers are stepping up to address. We’ll continue to monitor the fixes for Spectre and direct attack scenarios related to it as time progresses. This blog was written by: Kevin Haubris, Scott Nusbaum, and Justin Elze.