《SmashEx: Smashing SGX Enclaves Using Exceptions(CCS 2021)》阅读笔记

这篇论文核心是一个漏洞利用（自制论文Slide）

1. 攻击者在(EENTER)进入Enclave前让RSP等寄存器填充攻击者指定的值
2. 进入Enclave第一条指令处就对它进行中断，中断的方法包括页错误或时钟中断。此时中断触发SGX AEX，将寄存器状态备份到SSA，但此时寄存器尚未清理或改为可信值，仍然是攻击者准备的不可信值。
3. AEX后进入Enclave内异常处理句柄时
4. 由于Intel SGX SDK v2.13的Enclave异常句柄中没有考虑到SSA中的sp等寄存器是不可信值，因此从SSA中恢复了错误的值，如SP、R8等寄存器的值。Intel SGX SDK对此提交了一个Commit来修复该问题。
5. 因为能够控制关键的SP寄存器和其它的寄存器，结合异常处理函数里刚好有的代码，使得攻击者能够往Enclave内任意地址写任意值，此后直到如OCall返回指令处，这块地址内容都没被修改
6. 然后可以通过前述方法设置return地址来劫持控制流。
   

这篇工作进一步可以达到ROP的效果，并能通过一轮中多次尝试绕过ASLR。此外，对比先前的DarkROP、Guard Dilemma，不再需要假设代码已经存在某个漏洞。个人认为这篇工作相当于为DarkROP的成功等做了前提准备。

作者最后升华了一下，认为这个问题在于RE-EENTER，如刚进入Enclave到寄存器被清理这样的关键区域不应该被中断，然后又进入了Enclave。这需要相应的措施来防范。比如软件上延迟中断到关键区结束执行，或者在异常处理中模拟执行关键区中断后的剩余部分，又比如硬件上禁止RE-EENTER出现。个人认为硬件上让Enclave先在内部处理也能解决该问题，同时还能防范许多页表侧信道攻击。不过Intel Patch的做法就是在异常处理中检查t_SP不同于u_SP，但是光靠软件做诸如此类的判断确实是一件难以尽善尽美的事。