grsecurity - Cross-Process Spectre Exploitation
I have developed an exploit to demonstrate the impact of an incomplete Indirect Branch Prediction Barrier (IBPB) in Intel Golden Cove and Raptor Cove that I discovered. IBPB is meant to invalidate all indirect branch target predictions, which includes returns and jump/call instructions that take a memory or register operand (i.e., indirect branches). However, due to buggy microcode -- which appears to be an emergent problem in modern processors -- certain return target predictions are retained across IBPBs.
Back at ETH, Kaveh and I wrote a paper on this matter that we're publishing today along with this write-up. In the paper we also exploited a semantics issue of IBPB on certain AMD parts, leading to privileged memory disclosure on systems using IBPB-on-entry, which ironically is meant to be the more comprehensive mitigation alternative to the suspicious-looking, software-based SafeRET and retbleed thunk mitigations. In this write-up I will focus on the cross-process exploit, which is special for a couple of reasons.
Unlike OS-kernels, which are packed with 1000s of lines of code to select the appropriate mitigations to fend off cross-privilege Spectre attacks, user programs do nothing --- even if they run as root and manage sensitive information (e.g., OpenSSH, sudo, polkit). With this work, I hope to convince software authors of such programs to use IBPB. However, even if they did use IBPB, they would have been vulnerable to the attack I'll explain anyway. Intel has patched the IBPB issue in a microcode update released earlier this year, so now they would be safe.
