Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.
1453 Discussions

Tampered MRSIGNER or MRENCLAVE still allows Enclave executable to run

bergmann__Tina
Beginner
469 Views

Hi All,

 

I have downloaded the open source Linux SGX SDK(2.1 latest). I have built a simple application and am now evaluating the SGX Enclaves.

I am running my App in Hardware Debug mode. Having built the signed Enclave code(enclave.signed.so) I looked for the SIGSTRUCT and SGX Metadata addresses in my generated binary file(enclave.signed.so). Once I foudn theses addresses, I altered the Signature bytes and Enclave hash bytes and then tried to execute my binary(by calling ./app). The Enclave still got launched and no checks for the Hash or Signature was done- i.e, the Enclave got executed throwing no errors. What does this suppose to mean? I expected that since there has been a manipulation, the Enclave will prompt me with some errors. Please clarify!

Thanks,

Tina

0 Kudos
2 Replies
bergmann__Tina
Beginner
469 Views

Hi All,

 

Any update on this? Why is the platform not checking the SIGSTRUCT of the enclave.signed.so when launched using sgx_create_enclave?This is very important. Please throw some light on this.

thanks.

0 Kudos
Dr__Greg
Super User
469 Views
Good morning Tina, I hope this note finds your weekend going well. I believe what you are seeing is related to the other question you had on launch tokens. The Intel AESM implementation treats launch tokens as a 'bearer token'. Once it is created it will validate the initialization of an enclave as long as the measured contents of the enclave match what was used to create the launch token. The Linux PSW implementation caches the generated launch token in a file named 'token', I believe, in your home directory. If that token is valid it will be used to initialize the enclave that you named in the sgx_create_enclave() function. In that case I don't believe the contents of the enclave metadata will be relevant to the enclave getting loaded and executed. The only thing that matters is whether or not the loaded measurement of the enclave matches the initialization token. The last time I looked closely at that portion of the Intel AESM code was when we wrote the loader component of our PSW. I remember spending days grinding through those code paths in preparation for writing equivalent code. The code is not exactly straight forward but I believe the above is a valid general outline of what is going on. What I would recommend doing is seeing if execution of an enclave enabled application leaves anything lying around which remotely resembles a launch token. At the time we worked on the loader the Intel AESM code read the launch token into a 1,024 byte buffer and wrote the contents of that buffer to the cache file. A good place to start would be to look around for any files that are specifically that size and were recently created. You could then delete the cached token and then attempt to load an enclave with modified metadata to see if that results in a failure. If it doesn't that would be a very interesting finding. As an alternative test you could make a single byte modification to the contents of the actual data of the signed enclave. That should fail regardless of the status of the metadata. If it doesn't that would be an even more interesting finding. I hope the above is helpful, let us know the results of your testing. Have a good weekend and start of the next week. Dr. Greg
0 Kudos
Reply