This is the second post about Red Hat's John Masters presentation at FOSDEM 2018 presentation Exploiting Modern Microarchitectures: Meltdown, Spectre, and Other Attacks . The first part appeared in Breakfast Bytes yesterday. Todays' post covers Spectre and the limited approaches available for its mitigation. Spectre It is harder to explain Spectre than Meltdown without actually showing code, but let me give a flavor at least. Like Meltdown, the exploit works by running some code speculatively, meaning that eventually all the incorrectly executed code will be cleaned up without any direct effect... except that one item of data will have been loaded into the cache. By analyzing cache timing, it is possible to work out which item was loaded, and thus deduce what the data of interest must have been, even though the processor architecture never revealed it. It's like the Cheshire Cat in Alice in Wonderland, who gradually faded until all that was left was his smile. All that is left after running the gadget is one item in the cache that would not be there if the speculative code had never been executed and cleaned up, and which leaks a byte of secret data. Jon introduced Spectre with a "primer on exploiting 'gadgets' (gadget code)". A gadget is a piece of existing code in an existing program binary. It does not require the attacker to modify the binary. The attacker influences program control to cause the gadget code to run. The gadget code performs something that the attacker is interested in, such as loading sensitive secrets from privileged memory. In Paul's talk earlier the same week, he said that he had no trouble searching Windows and Microsoft Office to find suitable code for his gadgets. Spectre v1: Bounds Check Bypass The first gadget is (known as v1) is Bounds Check Bypass. The gadget checks an address is in range for an array, and if so accesses the array. But due to speculation, the access of the array may take place before the bounds check is done. As with buffer overflow vulnerabilities, the idea is not to access just off the end of the array, but to get a value in that is maybe megabytes away from the array. The access still may get done before the processor realizes that the bounds check failed. So using this approach it is potentially possible to access anywhere in memory. Existing hardware lacks the capability to limit speculation in this instance, so the mitigation is to modify the software to prevent the speculative load, by inserting a serializing "fence" instruction that speculation will not go past. However, this requires scanning source and binary files for offending sequences to fix, and right now it is painful. In Paul Kocher's taxonomy of approaches to mitigation, this is the hardware people throwing up their hands and telling the software people to find the cases that are problematic and fixing them up. Spectre v2: Branch Predictor Poisoning Modern microprocessors contain branch predictors which attempt to make an educated guess at whether a branch will be taken or not, so that the speculative execution can go on past the branch. It turns out that educated guesses are very good, getting it right 99+% of the time. One specific type of branch is an indirect branch, where the destination of the branch is in a register (not in the code). This exploit works by the rogue application training the indirect predictor so that it will predict a branch to the gadget. This works since only some of the bits of the instruction addresses are used in branch prediction, so the training can take place using one set of addresses, and the poisoned predictor will then predict a branch to the gadget. Privileged data can then be extracted using the same cache tricks as all the other exploits. I think it is easy to predict(!) that in the future, branch predictors will fully disambiguate addresses so this sort of poisoning will no longer work. But that doesn't work for existing processors. For existing processors, branch prediction needs to be partially limited. However, it can't just be turned off; that would result in a huge performance hit. One mitigation is to flush the predictor on context switch to a new application so that application-to-application attacks are prevented, and perhaps on entry to kernel or hypervisor. But a true solution may not be possible on existing processors. Chicken Bits and Microcode Modern processors need the ability to handle problems in the field. Actually, processors contain lots of bits that can enable or disable features that are not wanted, or do not work correctly, without requiring a re-spin. These are known as "chicken bits", since they allow the designer to chicken-out and disable features either in firmware or at system boot. For example, the branch predictor poisoning exploit could be mitigated if there was a chicken bit to disable indirect branch prediction (but chicken bits are not documented, so no one knows if there is one). Some CISC processors (x86, Power...) have simple instructions hardwired and complex ones microcoded. In general, microcode contains a mechanism for field upgrade of the microcode to make minor changes to instruction behavior. On the most recent x86 microprocessors, microcode adds new SPEC_CTRL model specific registers (MSRs) that can be used to restrict indirect branch speculation. However, many cores don't have this capability, and ones that do may have no convenient way to disable the branch predictors. Retpolines Retpolines stand for "return trampolines". Since indirect branches are the problem, the solution is not to use them. Instead of an indirect branch to a function, a little fake function stack is set up, and then return is used instead of the indirect call. At the same time, a harmless infinite loop is left for the CPU to speculate (or a fence to stop speculation in that branch). Google developed this idea, published them freely, and didn't patent it to encourage adoption. However, they are not a clean solution, requiring a recompilation of software, and perhaps dynamic patching to turn them off again on future silicon. There are also issues on some cores with the return stack buffer interacting with predictors and creating potential new vulnerabilities. Other Hardware Attacks Differential Power Analysis (DPA), also discovered by Paul Kocher. Rowhammer: this is a discovery that it is possible to perturb bits in DRAM by hammering the adjacent rows with frequent access. In particular, this can be used to flip bits in sensitive memory such as changing permissions in system page tables. MAGIC: this exploits negative temperature bias instability (NTBI) that affects the reliability of silicon transistors. It can be exploited to artificially age silicon devices and decrease longevity. Only proof of concept has been demonstrated (on SPARC). The Slides A pdf of Jon's presentation is on the Red Hat website . Note that it is 184 pages long since it contains the whole presentation in both slide form and note page form. If you want to print it out, you only need the first 90 pages (yes, still long). Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧