2017.W25 - 漏洞挖掘 以 The Stack Clash 為例 - 資安

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

--