压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

　　最近我在Linux上利用CERT BFF研究一個PoC。我之前有大量在Windows上寫PoC的經驗，所以認為將這種技能擴展到不同平臺上是個不錯的想法。可是，當我獲得指令指針的控制權后，卻發現幾乎可以毫無障礙地使代碼執行。

　　除了對Metasploit字符串做一個BFF最小化之外，不需要額外的工作，就可以很容易知道哪些字節在我的控制之下，以及怎么執行到那里：

　　運行起來之后，就控制了EIP(0×61626364 = "abcd")，得到一個Metasploit字符串模式，以及指向那里（EAX）的寄存器。下面我們看看這個位置的內存保護情況

　　不會是真的吧，這部分堆內存居然有讀、寫和執行權限！任意一塊內存既有可寫權限又有可執行權限都是一件非常危險的事情。為什么呢？以上述這種情況為例，其允許攻擊者將代碼跳轉到這里，并執行這些被系統認為是數據的字節。如果一塊內存區域被標記為可執行，NX是不會起作用的。（參考OpenBSD的W^X策略。）

　　我們需要花點時間找出為什么這塊堆內存是可執行的。我使用的平臺是UbuFuzz，基于Ubuntu 12.04.01，內核是x86 3.2.0。該平臺上，如果指定一塊可執行棧，例如用gcc編譯時指定-z execstack選項，進程的READ_IMPLIES_EXEC屬性就會被設置。正如其名，如果該位被設置，那么可讀的內存區域默認也同時變成可寫的了，包括堆內存（heap）。

　　問題是在崩潰進程的ELF頭部并沒有指定可執行棧：

　　GNU_STACK     0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4如果進程在編譯時沒有指定，默認是不會包含可執行棧的，但要是指定了READ_IMPLIES_EXEC特性會怎么樣呢？而且它也沒有顯式調用personality()函數。這就是比較奇怪的地方。如果崩潰的進程不是從終端直接調用的，而是由另一個不同的應用程序生成的，會怎么樣呢？下面我們看看其繼承自父進程的棧屬性：

　　GNU_STACK     0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4罪魁禍首找到了！其同時也證明了在x86 Linux平臺，READ_IMPLIES_EXEC屬性位會從父進程傳遞給子進程。這種行為是架構決定的，因為在amd64架構的平臺上，子進程就不會繼承READ_IMPLIES_EXEC特性。但在所有架構的平臺上，用來禁止ASLR的ADDR_NO_RANDOMIZE標記都會被子進程繼承。

　　總結

　　在vanilla Linux平臺，對于任意給定的進程，很難靜態地確定其啟用了哪些漏洞防護措施。在目前流行的X86平臺的Linux上，任何正在運行的進程都可能沒有啟用NX保護，只是因為其父進程沒有啟用相應的保護。