It must be Blackhat/DEFCON season. Up first in the storm of named vulnerabilities, we have Downfall. The PDF has the juicy details here. It’s quite similar to the Zenbleed issue from last week, in that it abuses speculative execution to leak data via a hidden register. Unlike Zenbleed, this isn’t direct access, but using cache timing analysis to extract individual bytes using a FLUSH+RELOAD approach.

The key to the vulnerability is the gather instruction, which pulls data from multiple locations in memory, often used to run a followup instruction on multiple bytes of data at once. The gather instruction is complex, takes multiple clock cycles to execute, and uses several tricks to execute faster, including managing buffers to avoid multiple reads. In certain cases, that instruction can be interrupted before it completes, leaving the data in the cache. And this data can be speculatively accessed and the values leaked through timing analysis.

This flaw affects 6th generation Intel Core processors through 11th. Mitigations are already rolling out via a microcode update, but do carry a performance hit for gather instructions.

Phantom and Inception

There’s another new issue, this time on the AMD side of the fence, called Inception. Taking it’s name from the movie, this one is all about tricking a CPU into believing a phantom speculation took place.

To understand that, we have to talk about Phantom (pdf), a technique that has an impact on all modern x86 processors. The key here is that processors do branch prediction all the time, to speed up execution flow. One of the tricks is to do branch prediction before even decoding instructions. This works by the CPU learning what code patterns are likely to be branches, and which branches are likely to be taken. Could that double prediction be abused somehow? Naturally.

So Phantom allows for training the CPU, such that a non-branching instruction still causes branch prediction. This can be used with another technique, Training in Transient Execution (TTE), to enable something interesting (pdf). See, TTE needs a specific code path that can be trained to speculate the wrong way. That path includes a reachable branch. But Phantom allows for an imagined branch, making many code paths into speculation gadgets.

To get all the CPU training done in the window, the attack does a really interesting trick — triggering speculative execution to get caught in a recursive loop. In dual-threaded mode, this is enough to completely overwrite the Return Stack Buffer (RSB), giving the Inception attack way more coverage. The results? On AMD Zen systems, only Zen 3 stands up well to the attack, with the rest of the CPUs tested leaking data, and even allowing a capture of the /etc/shadow contents in the majority of runs.

Dead Man’s Cable

You’re probably security conscious. Your hard drives are likely encrypted. You may even lock you desktop when you leave it, and never leave a laptop unattended. But what if you can’t? By accident or intent, what is the backup plan if you can’t power off or lock a device? That’s the problem the folks at Buskill are trying to help solve. The idea is pretty simple — a USB device that indicates user presence.

Connect it to your body with a cable, detect the unplug, and lock the machine. The key here is to 3D-print a case, that makes that USB connection with pogo pins and a magnetic plug. Make it easy to break the connection, and hard to make a laptop come crashing down by mistake.

Bits and Bytes

It’s a bit ignominious to have the record for a country’s biggest hack ever, but that seems to be the award that Microsoft’s Exchange software now has. The UK Electoral Commission Has just announced that their systems were accessed way back in August 2021, and not discovered for 14 months. The timing here is interesting, as the ProxyNotShell vulnerability that is suspected to be the entry vector for this attack wasn’t publicly discovered until 2022.

Security by committee doesn’t tend to go very well, even when the results are open source. The Open Supervised Device Protocol (OSDP) is supposed to keep data secure between a card reader and the central database. It was retrofitted with a Secure Channel add-on, in response to a previous eavesdropping attack. But it turns out that OSDP has some of the same problems. The Mellon device is about quarter sized, and when tapped into the serial connection that runs an OSDP connection, it can capture the encryption key used to secure the system. Speak friend and enter, indeed.

Keyboards on mobile devices can be a problem, because the keyboard is usually an app, and that app has access to all your keystrokes. The usual advice is to never use a keyboard that asks for network access, but what if really does need the cloud to do its job? That’s the story with the Sogou keyboard, which uses Latin character inputs to generate Chinese characters. The heavy lifting happens in the cloud, which means all those keystrokes get sent over the internet by design. To make it worse, the encryption scheme it uses is terrible, and the Windows and Android versions of the app are vulnerable to sniffing attacks, such that a third party could capture that information. Yikes!

And finally, tip of the hat to [Myself] in the Hackaday discord server for the opening lines and inspiration for the name of this week’s installment of the column.