Zipper Stack

Zipper Stack相关工作介绍

Posted by Readm on July 27, 2020

Zipper Stack工作介绍

论文

经过漫长的等待,Zipper Stack这篇文章终于被ESORICS 2020接收了,可以在自己的博客里做一个简单的介绍和总结了。

预印版本

后续正式出版我会更新链接。

声明

欢迎感兴趣的研究者与我联系讨论,最近也在找工作,有相关的岗位欢迎联系。不过该设计已经申请专利(若干项),因此如果希望使用还是请联系讨论授权事宜。

简介

Zipper Stack主要是用于保护内存中返回地址的一种新型安全机制。这可以阻止目前最常见的ROP攻击,也可以使得栈溢出漏洞无法直接通过返回地址挟持控制流。在学术中我们可以称之为后向的控制流完整性保护(CFI)。

背景

目前后向控制流完整性保护主要有两个技术路线:

影子栈

影子栈的思路主要是讲返回地址在内存中再备份一份,并在返回时对比栈中的地址和备份是否一致。这种思路的主要优点是比较简单,性能开销也比较低。缺点就是十分依赖于影子栈本身的安全性。因为在内存攻击中,经常假设攻击者可以任意的读写多数内存的,如何保护影子栈成为了关键:

  • 使用ASLR来隐藏影子栈:这种方式比较简单,但其实安全性很低,因为针对ASLR的去随机化攻击可以说是一抓一大把了。
  • 使用内存隔离:要借助一些其他的硬件机制。
  • Intel CET中使用一个全新的页属性:这种安全性要等实际部署才能评估了,因为DEP也是使用页属性保护,但是绕过的方式也很多。

这个思路下还有一些类似的设计,比如SafeStack等等。

MAC验证

MAC验证可以应用于多数的代码指针,当然也包括返回地址。目前商用CPU中有计划的例子就是ARMv8.3中的Pointer Authentication(PA),简单来说就是为每个指针生成一个MAC,并在使用时验证MAC是否正确。这种保护主要依赖于秘钥的安全性。这种思路的有点也是比较简单,但是缺点也很明显:

  • 使用MAC意味着复杂的计算,代码指针尤其是返回地址在应用程序中的使用非常频繁,因此无法承受过于复杂的MAC计算,只能设计轻量级的快速MAC计算模块。
  • 重放攻击:攻击者可以复用内存内已知的代码指针和其正确的MAC。PA中预留了一个modifier用来给相同的指针生成不同的MAC,但如何选取modifier依然是一个麻烦的问题。

Zipper Stack

Zipper Stack是我们新提出的基于链式MAC来保护程序中所有返回地址的安全机制。简要的示意图如下:

Zipper Stack

简单来说,我们把所有的MAC值放到一个链中,可以看做是每个区块只包含一个返回地址的区块链。每个MAC的输入除了Key以外,还包括返回地址和与这个返回地址绑定的MAC,而这个MAC并不与当前的返回地址一同存储,而是存储在下一个返回地址的旁边。而最新的返回地址和其MAC生成的新MAC存放在一个特殊的寄存器中(Top寄存器)。

这个看起来复杂的内存布局如何在程序执行call和return时操作呢?实际上非常简单:

操作

除了正常的栈操作外:

  • Call时将Top寄存器的值随返回地址一同压栈,且更新Top寄存器。
  • Return时先验证MAC是否正确,然后用栈上弹出的MAC值更新Top寄存器。

直觉上,这似乎太简单了。因为很多这种链式结构都需要记录指针(上一个或者下一个)。因为调用和返回实在太过频繁,因此记录指针是几乎不可以容忍的开销。好在有了Top寄存器,我们其实并不需要显式的维护这个链式结构。

优势

Zipper Stack相对于之前设计的优势还是非常明显的:

  • 相对于影子栈:
    • 不需要额外的影子栈内存的保护(这也是所有基于MAC的方法的优势)
  • 相对于普通MAC:
    • 不必担心秘钥泄露:在论文中有详细的阐述,即使攻击者得知当前的秘钥,攻击者也无法修改Top寄存器。唯一可能的途径是构造哈希碰撞,而这几乎不可能:
      • 每个配件构造一次
      • 每次程序运行需要重新构造
      • 每个配件构造时有一定概率不存在可能的碰撞,5个配件此概率大于90%
    • 天然抵抗复用攻击,相同的地址再次使用时MAC不同:我们不再需要想方设法构造modifier了。
    • 速度快:因为哈希计算和访存/寄存器更新可以并行,因此我们可以容忍更加复杂,消耗更多周期的MAC算法。一个示意图如下。

总结来说,我们使用了比PA技术更低的运行时开销达到了更高的安全性:

  • 相同MAC算法Zipper Stack更快,相同速度Zipper Stack可以使用更复杂的MAC。
  • 我们可以容忍秘钥泄露,并且暴力破解的难度更高。

缺点:

Zipper Stack也有一定的缺点:依赖于栈的FILO序列,因此当这个序列被破坏时需要一定的修复。也就是异常处理需要更加复杂。下面是三种不同方式的异常处理:

  • Zipper Stack:备份并恢复Top寄存器。
  • 影子栈:备份并恢复影子栈指针。
  • MAC:不需要任何操作。

在论文的评审中,评委还是比较看重这里造成的复杂度和安全性的。因为一般异常处理的现场需要在内存中保护,而Top寄存器是需要假设攻击者无法改写的。因此我在这里设计上下文切换也是需要MAC保护的。实际上我并不认为这是个明显的缺点:

  • 上下文切换造成的安全隐患本身就非常多,这并不是Zipper Stack引入的。
  • 熟悉攻击的都知道,影子栈指针虽然看起来人畜无害,但是实际上能控制指针约等于能控制数据,所以影子栈指针也面临基本一样的问题。并且影子栈并不存在其他保护措施(MAC),因此更加危险。

在博客中我就仅仅介绍思想和设计了,更多细节请参考论文,有兴趣和以为的欢迎联系我进一步讨论。

IDEA来源

这个idea看起来比较像是从区块链来的,然而其实最初的idea来源主要是思考如何能够提高直接MAC保护。最初我认为如果一个MAC的Key是不断变化的,那么攻击难度应该是增加了很多。最初的idea就是使用上一次的MAC作为下一次的Key来使用,这样可以使Key滚动。但是实际上并没有增加信息量,因此我也直觉上认为这不应该提高攻击难度。仔细思考了之后发现确实不行。后来逐渐修改,形成了最后的设计。

写在最后

这篇论文其实从2018年就基本成型了,拖了两年,主要有以下的原因:一是我比较贪心,希望能中安全的顶会,因此一直不甘心,最后中了个ESORICS也算不亏了。二是家庭变故导致一年没什么认真工作的机会。三是第一次发论文经验不足,不仅最初写的惨不忍睹(在此要感谢陈恺老师的指导,非常关键)而且最初对标的是影子栈,思路是错误的。如果当初直接调研到PA,估计行文会更加流畅,也不至于被人直接用ARM PA直接做一个类似的版本抢结果了。评委提醒我有其他人跟我一样的核心思想(他们先发了一个DAC的Work in Progress)的时候还是很崩溃的,早知道不发arxiv了o(╥﹏╥)o。

另一点感悟还是不要妄自菲薄,当初刚形成这个idea的时候很担心以后也就没啥更好的idea了,因此重视程度过高。实际上这篇文章刚中不就,我的其他工作也被接收了,还是更好的期刊(这个是CCF-B类,而后面是A类)。所以还是要眼光长远,不要拘泥于眼前的得失。

不论如何,这个工作算是我第一个作品了,现在尘埃落定我还是比较欣慰了。ESORICS也是比较合适的归宿了。