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