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 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.193.122.171 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/NetSecurity/M.1497968980.A.0CE.html ※ 编辑: CMJ0121 (123.193.122.171), 06/20/2017 22:35:36