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/m.aspx?n=bbs/NetSecurity/M.1497968980.A.0CE.html ※ 編輯: CMJ0121 (123.193.122.171), 06/20/2017 22:35:36