- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could we have an official statement from Intel (or an educated guess) regarding the impact of the newly discovered Meltdown/Spectre attacks on SGX? Are secrets stored inside an enclave at risk? This has been asked at https://security.stackexchange.com/questions/176635/how-does-meltdown-spectre-impact-intel-sgx (by someone else) as well, but no replies so far.
Could someone please clarify this?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
My name is Dan O'Keeffe from the LSDS group at Imperial College London. We've just released a proof-of-concept spectre-like attack on Intel SGX enclaves on github: https://github.com/lsds/spectre-attack-sgx. Be interested to hear your opinion.
Thanks!
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick note to say that we would also be interested in a statement as to the impact of Spectre on SGX.
Regards,
-Arthur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for that detailed post Greg W.
I think I agree with you on all the points after reading those sources. I am envisioning Meltdown attack on enclaves as a scenario where non-enclave code will try to access memory in the enclave ELRANGE. I have two questions --
- From reading the architectural specification documents and Devadas's paper, is your conclusion that the MEE will be independent of any access checks, i.e. the data from ELRANGE will be decrypted regardless, but then the access checks will have subsequent to that, meaning that decrypted data will be available in the cache for the attack to happen.
- The Meltdown paper says that the attack depends on leaking the micro-architectural effects of reading otherwise inaccessible memory by executing a set of data-dependent instructions that will never be retired because the original illegal memory access will lead to an exception. In the case of mounting a meltdown attack in enclaves, there wouldn't really be an exception -- rather the illegal access would result in Abort Page semantics which will replace the data read with all 1s. So the subsequent data dependent instructions will continue to be executed with this replaced data and be retired - so that may add noise/negate the micro-architectural effects?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greg W. wrote:
In reading the architectural documents it is tempting to assume that enclaves would not be vulnerable since they talk about ENCLU[EENTER], ENCLU[ERESUME] and ENCLU[EEXIT] instructions being serialization points where the TLB cache and out-of-order execution pipelines are flushed. The primary security premise is that the SGX modifications to the hardware PMH are effective in blocking a page fetch from being reflected as a TLB fill. Unfortunately, it appears as if this check, as in the case of page access protection checks, occurs too late to defend against a micro-architectural state probe.
The invariant case one premise for the SGX security induction proof requires that when a processor is outside of enclave mode the TLB can only contain physical addresses belonging to DRAM pages outside the enclave. The induction moves forward on the premise that any attempts to access enclave memory will be rejected and replaced with an abort page by the PMH. Unfortunately, this supposition appears to be invalid with respect to the actual micro-architectural state of memory.
are you saying that the PMH actually is allowed to read and fill the TLB with the 'victim' entry, then second consult the EPCM and check whether it is a valid access or not, and remove it from the TLB eventually if it is not? could you provide any references about that please?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have we still not got an official statement from Intel regarding the impact of the Meltdown/Spectre attacks on SGX?
Come on Intel we are waiting, I have directors asking if it is worth investing in SGX or should we be investing in alternative technologies. All the time Intel remain quiet it becomes harder to make the case for SGX.
We have now been waiting for 2 weeks, we need an official statement.
Regards,
-Arthur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no engineering rationale to support the conclusion that data consigned to an enclave would have an expectation of confidentiality protections in the face of these micro-architectural cache probing attacks. Unless opposing rationale can be afforded, the operative security premise must be that there is no guarantee for enclaves providing confidentiality or runtime encryption protections for 'data in motion' in the face of this particular threat scenario.
In support of this we have an operational implementation of the Spectre conditional branch misprediction attack running in our labs which is demonstrating an 88% accuracy rate with respect to exfiltration of data inside of an enclave. This attack has the standard limitation of needing to be conducted by a process on itself, but it does provide the single instance proof needed to demonstrate that untrusted code can reliably infer the contents of data protected by an enclave encryption envelope and virtual memory protections. There is a high probability that demonstrating a rogue cache fill, ie. Meltdown, attack is just a matter of putting in the necessary time.
The engineering rationale for this makes sense given the design of SGX. We are working to put together a white paper which explains all of this, including immediately practical mitigations. We will defer greater detail to that in order to avoid a TLDR phenomenon in this forum.
Before everyone throws out the baby with the bathwater it is important to note there is currently no indication of threat to enclave integrity, which is an extremely important tool to have in the toolbox when building high security assurance systems.
Best wishes for a pleasant weekend to everyone.
Dr. Greg
Disclaimer: We do not speak for Intel and there is probably remarkably little probability that Intel would want us to speak for them... :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Greg W
Thanks for your (well written) thoughts.
I agree that based on the information that we currently have SGX enclaves don’t provide confidentiality guarantees, however integrity guarantees appear to be unaffected.
On this basis additional measures need to be used with the SGX to provide the confidentiality that Intel advertise the SGX as providing. I note that Intel do state that they don’t protect against side channel attacks, but the PoC code shows how permeable the cache is between the enclave and the calling code.
My question is can Intel address this in microcode, do they recommend software measures (if so what) or do we have to wait for a new hardware architecture before the SGX provides the advertised confidentiality?
The failure of Intel to comment leads me to conclude that we need to wait for a new hardware architecture.
Regards,
-Arthur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf
Speaking to Gordon's concerns, we have included a discussion of potential mitigations that can be immediately implemented to protect SGX confidentiality guarantees. We also believe there is a strong possibility that Intel will be able to modify the behavior of enclaves on current hardware to provide significant strengthening of enclaves to speculative exfiltration attacks. Those fixes may already be there and be testable but we haven't had the bandwidth for that. Given the stability concerns over the current crop of microcode we have taken a go slow approach to testing it. It doesn't seem likely that Intel will be in a position to implement major operational level changes in the Page Miss Handler with microcode updates, but that is only speculation... :-) As our paper discusses, the security design of SGX is based on a virtual memory model and the inherent problem with these vulnerabilities is that they are extracting information from the operational level of the processor where, by design, the microcode/micro-ops have unconditional ability to fetch memory pages through the MM{U,E} infrastructure. Hopefully all of this will be helpful. Have a good weekend. Dr. Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greg W. wrote:There is therefore some reason to believe that while Meltdown could be used to discern the contents of enclave memory the best that could be accomplished would be to discern the value of the encrypted bytes, which would by definition be as secure as the quality of the encryption.
Unfortunately these speculations proved to be wrong as demonstrated by the "Foreshadow exploit".
Is it safe to assume that "Foreshadow" has been already fixed in recent versions of SGX?
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page