2017.W25 - 漏洞挖掘 以 The Stack Clash 为例
> Bounty Hunter 说简单很简单 说难也很难
## 前言 ##
最近在处理一些事情 突然觉得要当专职 Bounty Hunter
说简单真的很简单 说难也真的很难
端看你找到的漏洞有多严重...
简单的可以从 HTTPOnly Flag 没有设定
难到 libc memory stack 跨界存取
## 内容 ##
这次其实不准备讲怎样挖掘漏洞 (因为我也不会QQ)
而是想提到最近有点严重的漏洞 叫做 Stack Clash[0] 或者是 CVE-2017-1000364[1]
在之前已经有类似的研究 不过自从有 GCC 的 stack guard-page[2] 后
似乎也没出现显著的突破技术
在这次 Qualys 找到的漏洞报告[4] 中提到关于 Stach Expansion 的几个问题：
1. 内存直接开在 stack 后则不会出现 page-fault
2. kernel 无法通知 process 需要更多的 stack
3. process 无法通知 kernel 转换他的 stack 区块
在 GCC 中利用 stack guard-page 来保护 stack 的范围
借由在 stack 后的空间使用 PROT_NONE 的内存空间
让存取到这块区域的 process 自动产生 SIGSEGV
但是这块区域大小也只有几 KB 而已 这也是这次问题的原因之一
如果 buffer-overflow 可以直接跳过这一个 guard-page
就可以成功的绕过这个保护机制
这次的 Stack Clash 有四个攻击顺序：Clash、Run、Jump 跟 Smash
更多的细节 就参考 Qualys 的报告吧～
一些经典漏洞 (e.g. Injection、XSS) 可以借由 Code Review 来发掘
原因在于这些漏洞的成因 主要都来自于不正确的 Coding Style
像是使用自己组出来的指令语法
然而一些更加底层的安全性漏洞 通常来自于软件架构与不正确的假设
像是经典的故事：640 kB Is enough[5] 就是一个不正确的假设
在早期 使用 RC4、MD5 等算法似乎是一个可行且安全方案
但是这都假设在没有更加强大的硬件 与没有缺陷的算法
因此实作的时候 需要花更多的时间思考架构上是否存在根本上的漏洞
不然就会再出现 使用 base64 加密的神奇技巧了
[0]: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
[1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000364
[2]: https://en.wikipedia.org/wiki/Buffer_overflow_protection
[3]: https://www.qualys.com/
[4]: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[5]: https://en.wikiquote.org/wiki/Talk:Bill_Gates#640_k.2F1_MB