This sounds a lot like the CRIME attack in that a miscreant can take advantage of some efficiency improvement (compression in CRIME, a lookup table here) to circumvent obfuscation. Which kind of puts you in a bind since in the last the only way to block these kinds of exploits is to run code INefficiently, which has consequences of their own.
Boffins exploit Intel CPU weakness to run rings around code defenses
US researchers have pinpointed a vulnerability in Intel chips – and possibly other processor families – that clears the way for circumventing a popular operating-system-level security control. ASLR (address space layout randomization) is widely used as a defense against attempts by hackers to exploit software vulnerabilities …
COMMENTS
-
Thursday 20th October 2016 19:08 GMT Destroy All Monsters
Neo code!
So you can guess the contents of the Branch Target Buffer from user-level software using timing? That's pretty meta. We might find that "destroy on read" Quantum Mechanics is Nature's surefire way to prevent any breakouts from Her Virtual Machine.
The hack takes advantage of the CPU's branch target buffer, a mechanism present in many microprocessor architectures including Intel Haswell CPUs.
In most CPUs since the 90's I would guess.
The paper has some recommendations though:
A hardware solution that would fundamentally mitigate the BTB-based attacks is to change the BTB addressing mechanism in a way that prevents exploitable collisions in the BTB. The attack against KASLR can be mitigated by using full virtual address for accessing the BTB, thus eliminating collisions between the user code and the kernel code. This would require adding extra bits in the BTB, as the tag size will increase significantly (by 17 bits compared to Haswell implementation for 48-bit virtual addresses). Alternatively, the BTB can use different indexing functions for user and kernel-level code. For example, a secret value can be added to the existing BTB hash function when the CPU is executing in the kernel mode. To prevent the user process from discovering this value and reverse-engineering the hash function, this value can be randomized during each system’s boot.
-
Thursday 20th October 2016 21:12 GMT Anonymous Coward
Non sequitur?
...miscreants must be able to at least start running their malicious code within an application or operating system on the target machine – this isn't a remote attack, it's a local attack.
Um, what?
dependent on a remote code execution flaw != "a local attack"
It's hardly as if remote code execution flaws are unheard of, now, is it?!!!!!!!!!oneoneone
-
Friday 21st October 2016 05:26 GMT diodesign
Re: Non sequitur?
All right, all right. The BTB part is local. It's needed to defeat ASLR. You need to defeat ASLR whether you're coming remotely or local. That part is local.
In other words, we were trying to make it clear that you don't attack the BTB + ASLR from outside and then install your malware. You first gain basic code execution (remote or local) and then exploit the BTB to get past ASLR (local).
I've taken that bit out since it seems to have blown your mind.
C.
-
Friday 21st October 2016 04:31 GMT JLV
And this is why folks that compare securing software and IT assets against tampering to our fairly high, but reasonable, expectations of service quality from, say, an electric power utility company or civil engineering are, IMHO, off the mark.
Software is hard and both assets and threats are constantly mutating. Doesn't mean we shouldn't try but foolproof sec is a pie in the sky. Damage mitigation, detection and resilience are needed to catch what slips through.