The bleeding cloud: new exploit based on hyperthread leaking
The ‘snoop thy neighbour’ train continues. Spectre, in the news for most of last year, is a method by which you can snoop on other process memory on the same box. And this in an age of ‘sharing is caring’ where you are running your high-value SSL eCommerce site on the same physical machine that, well, anyone is sharing.
So today’s the news came out about TLBleed. It uses hyper-thread occupancy (2 register sets share 1 pipeline and stall on memory operations) to snoop. And, they appear to have:
… calculating cryptographic signatures using the Curve 25519 EdDSA algorithm implemented in libgcrypt on one logical core and their attack program on the other logical core. The attack program could determine the 256-bit encryption key used to calculate the signature with a combination of two milliseconds of observation, followed by 17 seconds of machine-learning-driven guessing and a final fraction of a second of brute-force guessing.
So, this means you can find the ssh private key of your neighbour, in a different memory space, a different VM.
Now, a little bit of scheduling magic, and one could guarantee that hyper-thread pairs are never scheduled out of the same VM, that would be a sufficient workaround for the threat of ‘someone else’, but still allow local privilege escalation.
Trust. Inside out, outside in, left to right. Its getting harder to have that trust. Pretty soon someone will launch a ‘deterministic processor’. All instructions will take 1-second, no variation, and be in-order. it will have 1K of ram. It might say 6502 or z80 on the front. Maybe it doesn’t support branching or conditions!. And we’ll examine Amdahl’s law as we try to cluster them for security 🙂