'007' code helps stop Spectre exploits before they exist Black hats haven't yet found a way to mass-exploit the Spectre vulnerability – but mitigations are already arriving. Beyond chip vendor and operating system patches, there remain reasons to seek out additional defences: there are still circumstances in which protective coverage is incomplete – and over in the world of Android …
Have you never encountered 'obfuscated binaries'?
Can you explain which binary-obfuscation techniques would be a problem for the 007 detection technique (which is what I assume you're referring to, though your posts achieved an impressive degree of vagueness), and why? Frankly, I'm not seeing the issue.
Aside from encryption and similar techniques used to protect shellcode and similar malware - which would hardly be a concern, because why do you care if shellcode is vulnerable to Spectre? - most binary-obfuscation techniques don't alter flow within basic blocks, which is primarily what we're concerned with here.
You don't understand what a variable length of instructions implies. So let's break this down:
Imagine seeing a screen full of hex-code. Depending on which location in this hex-code you jump to, it transforms into different instructions.
In order to obfuscate, all you need is to do some complicated calculation and jump to an address based on that calculation. As a result, you won't be able to tell what is being executed without decrypting the calculation. On a system with variable length instructions you can't even tell what possible code there is until you know where 'the entry point is', which in the obfuscated case would require you to decrypt the calculation...
If we're talking about oo7, then de-obfuscation is not needed. The purpose of oo7 is to protect vulnerable but naturally benign software from being exploited via the Spector vector. Moreover, oo7 fixes the code on the source level. Only the detection is performed on the binary level. But still, the binary is obtained from the source code.
P.S. with all these said, oo7, at least the detector is still quite robust to obfuscation, as it uses the Microexecution underneath the hood, thus all jump targets are computed. Of course, it is still possible to beat it using different anti-emulation techniques. But this battle will never end, you know.
Sorry, but stating that Android updates dribble out slowly is being generous! The fragmented update scene is more like an army of snails, all with a severe limp, advancing towards the besieged and vulnerable phones and tablets. Most won't make it, and those that do will be too late; the war will be over and the device will either have been hacked, rooted or bunged in the bin.
Say what you will about Microsoft's attitudes concerning updates, but at least you can get them (whether you want them or not). Google's method of giving updates to manufacturers instead of directly may result in better update testing but can result in vast delays and in a lot of cases no updates being issued at all for even slightly older devices.
I don't know the solution to this, but then again what do my views matter? I'm just a user. I'm not making £millions.
This depends on the architecture. On some you can't check for that instruction, because instructions don't have a fixed size. This is the case on Intel x86/x64 systems, for instance. From simply scanning a file from top to bottom you can't tell what is the beginning or the end of an instruction. Depending on where you start (jump to), it can receive a different meaning and have a different length.
Okay, I'm more than just a bit confused by this discussion. To review, I spent a decade doing microprocessor validation at AMD & IBM for a decade starting in the mid 90's. As I understand it, Spectre works by poisoning the branch prediction mechanism to cause a speculative memory fetch involving a value in a register which was read from an address controlled by an attacker. Timing of subsequent reads from the possible locations of the speculative read reveals the contents of the attacked address.
What about this requires a cache flush operation? All you need to do is to execute enough reads on the caches aliases. That seems a lot more difficult to detect than a straight cache flush operation.
Spectre-class attacks don't necessary require branch-prediction poisoning or cache timing. There are side channels in speculative execution that don't involve either of those mechanisms (in some processor architectures).
Even when a spec-ex side-channel attack does involve the cache, a flush isn't strictly necessary. Flushing is just an optimization so that the attack can leak information at a rate that makes exploitation feasible; and as the original Yarom and Falkner paper notes, their original FLUSH+RELOAD attack has the advantage of targeting the L3 cache, so the attacking process need not be running on the same core. And there are other approaches which don't require flushing.
Some references: The Yarom and Falkner FLUSH+RELOAD paper. DJB's classic 2005 paper on cache side-channel key extraction, which popularized the need for constant-time crypto; no flushes involved there (but it's a different sort of attack). From 2009, there's Brumley and Hakala showing some fancier flushless cache-timing attacks, using trace data. For flushing without reloading, see Gruss et al. There are also instruction-cache attacks and other variants; you can find references in those papers.
There's a paper that describes various cache side-channel attacks, including some with and without flushing, but I can't recall the author or title at the moment, and a quick search didn't turn it up. In any case, though, the point is that flush-based attacks are just one of the more convenient options.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
