Spectre haunts Intel's SGX defense: CPU flaws can be exploited to snoop on enclaves The Spectre design flaws in modern CPUs can be exploited to punch holes through the walls of Intel's SGX secure environments, researchers claim. SGX – short for Software Guard eXtensions – is a mechanism that normal applications can use to ring-fence sections of memory that not even the operating system nor a hypervisor can …
Who owns the tin, owns the data.The way it has always been, the way it will always be ... seven of five
Oh? Is one so sure?
Does not the tale tell whoever supplies the data, pwns the tin? And is that not the way it has always been, the way it will always be.
If you own the tin, in a bofh scenario, can you provide a broken sgx api anyway? With or without spectre?... teknopaul
Quite so, teknopaul, .... Own Command and Control with IT and their AIs. Can you Imagine to Realise their Future Programs for Picture ReProgramming with AIMedia Presentations from Colossal and Titanic Studio Organs ........ Birthing Areas for Alien Landers on Earth ........ where TS/SCI Scripts are Enlivened and AIRealised with Universal Broad Band Casting ........ so you get to see the Future Arriving just as IT and Media are showing you with talking pictures/selected program actor.
Just checking Wikipedia https://en.wikipedia.org/wiki/Software_Guard_Extensions#cite_note-14 we see that
a) There was a Prime+Probe attack which used "certain CPU instructions in lieu of a fine-grained timer to exploit cache DRAM side-channels" and a coutermeasure was published
b) The LSDS group at Imperial College London showed a proof of concept that the Spectre speculative execution security vulnerability can be adapted to attack the secure enclave and the code is dated 2 months ago.
I wonder if the "compiler-based tool, DR.SGX" which was a coutermeasure for Prime+Probe could be extended to handle Spectre?
It finally comes to light as I predicted a couple of months back that trusted zone memory would be up for grabs, see:
https://forums.theregister.co.uk/forum/2/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/
It has taken the white hats a couple of months ( maybe a little longer as it was known about before we , the great unwashed, got to know about it), Historically they have always trailed the black hats in exploit finding. though maybe not so far behind now there are bug bounties.
All stored key protection schemes are now totally insecure. By this I mean just about every DRM scheme which is in place up to now. I reiterate, watch the sue-balls fly from the fallout of this.
It's not just DRM, it's anything that uses a password. Most software was written with poor security, i.e., passwords in the clear all the time, etc. If they even bothered with rot13 it would be an improvement.
Keep a password encrypted until use, and then overwrite the plain text after you're done with it. Sorted.
Keep a password encrypted until use, and then overwrite the plain text after you're done with it. Sorted.
You need the keys in memory too though, so this is a form of security by obscurity. A relatively tough one, but someone motivated enough to get into an application's secured memory area is also going to be able to deal with that. Unless you're doing completely homomorphic computation (I'm not sure it's actually possible and still decodeable at a low cost) control of the hardware always offers the potential to compromise a system running on it. Encryption at rest is a different thing which you can achieve.
from what I understand, the practicality of the attack vs possibility is a completely different thing.
As much as I'd like to see the Blu-Ray equivalent of 'libdecss' with all of the possible decryption keys built-in, and easily downloadable software to convert Blu-Ray contents into h.265 media files on a computer, phone, or slab [for personal use, of course, I'm not interested in pirating content, just convenience], I don't see this happening any time soon, even with the ability to do a side-channel attack on the DRM code.
It just seems that there's a lot of cost for such a tiny payoff that it probably won't happen outside of specific kinds of "spear" attacks [perhaps by the NSA?].
In the mean time, every time I read into the technical details of these things, my mind boggles. Spectre is such a confusing mess to try and wrap my mind around, I can't see how any *SANE* person could actually make this work without an extreme amount of time and effort...
And the 'ret-poline' seems to be an adequate defense against at least SOME of it, by not using the speculative execution thingy in the first place.
Now, here's a thought: what if we could just flip a bit to turn branch prediction OFF for code that needs extra security? Or, better still, make it an inherent part of the TASK STATE so other CPU tasks can't pollute the branch prediction cache like that.
yeah that means a complete re-design of the chip's internals. I'll have to wait for a new CPU architecture before upgrading hardware, then... hopefully withOUT a mandatory management engine, too!
A back-of-the envelope computation suggests that branch prediction might be doubling performance in processor-bound applications. If you think that microprocessor designs are complicated today, just wait until you see what comes out to try to claw back the performance losses.
But of course, it's pretty rare to have processor-bound code. The real bottleneck is almost always memory or IO. Caches are there to help with that, but it is the speculative loads & stores that really win here. And are creating most of these vulnerabilities. So we're talking pre- and/or post- buffers on the caches.
Complicated.
The problem is if there's a way to do it then one sufficiently clever person may be able to automate it.
For bluray I suppose the difficulty (a number of different schemes and not as trivially flawed as CSS was) combined with the potential for becoming a criminal for breaking it outweigh the fairly small rewards of developing and open-sourcing a general solution. Additionally newer versions apparently have corrupt data on the disc and rely on online retrieval of correction tables, which sounds compromisable but also designed to get you into hot water if you tried it. (I think there may be some approaches that work for some cases, but generally you still can't expect to watch a legal blueray in linux without using a commercial player).
"And the 'ret-poline' seems to be an adequate defense against at least SOME of it, by not using the speculative execution thingy in the first place."
Retpoline doesn't get in the way of most speculative execution; that would make the penalty of the Meltdown mitigation look positively light-weight in comparison. Instead, it tricks the processor into treating simple jumps as function calls, which are handled differently(though our buddies at Intel have managed to screw up that bit of security: in the right circumstances, newer models can starting reading from the vulnerable branch buffer rather than the secure return buffer).
This post from Stack Overflow explains it a lot better than I ever could.
Maybe it's the death of *cheap* DRM ?
You could have expensive DRM, but that would be predicated on the thing being "managed" to be of enough value to make it worthwhile. Our old friend Laffey is at work here, as elsewhere, methinks.
That's before we get to the fact that - disingenuously - it can suit big companies to have slightly leaky DRM. They'll get their whack from the merchandising and tie-in stuff.
You need only be able to have a vulnerability so that you can inject your code in. This can be triggered when you, for example, visit a malicious website or have a spearfishing email. Just one of the few examples. Moreover, most trusted enclaves run code in the processor's internal static ram and reference data (including keys) in the static ram itself. In theory external code can't see the internals of this static ram. That section of static ram is not cached out to the general CPU cache. These researchers found a way to cross the wall because of speculative instruction execution.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
