- 緩衝區溢出和返回到libc攻擊之間的區別

Question

我想了解這兩種攻擊類型之間的確切區別。從我已閱讀：

緩衝區溢出：它覆蓋棧上的RET地址爲指向惡意代碼插入代碼的另一部分。非常有效 - 在這裏我們需要修改程序的源代碼以實際執行攻擊。

返回Libc-這裏不是修改源代碼，由C庫提供運行時功能調用用來（說打開一個shell）。這裏用於函數調用的參數也在覆蓋緩衝區中傳遞，最終在堆棧的ret部分之後結束。

以上是一個準確的描述嗎？

而另一個相關的問題 - 這將是可能有，而不真正修改原始程序的源代碼中的緩衝區溢出攻擊？如果我們編寫一個新程序並允許修改某些內存段（這是原始程序損壞的堆棧中新的ret地址），那可能就是這種情況。再次，我認爲這可能是不可能的，因爲內核中的進程之間提供了內存保護。

Answer 1

在經典的緩衝器溢出攻擊，要執行被溢出填充有兩者的機器代碼的堆棧緩衝器（稱爲殼碼，因爲它典型地調用一個外殼進程）和新的返回地址。新的返回地址將被製作成指向溢出堆棧緩衝區本身。顯然，這需要知道或猜測攻擊過程中堆棧緩衝區的地址。

在那些日子裏，進程的內存佈局通常是非常確定性的 - 通常攻擊者可以很好地預測堆棧緩衝區的位置（特別是如果他們知道目標軟件的哪個版本正在被攻擊）。爲了在涉及一些猜測時提高成功機率，活動shellcode往往會有大量可執行的機器代碼，它們不會執行任何有用的操作 - 稱爲「NOP sled」或「NOP slide」，其中「NOP」是執行「無操作」的機器代碼指令的典型名稱。回到NOP底座的任何一點都會產生預期的效果。

「迴歸到libc的」漏洞，而另一方面，不會引起被劫持的過程中直接返回的shellcode。相反，它會使進程逐一返回到一​​系列庫函數的開始。這些庫函數可能直接執行攻擊者想要的操作，但更常見的是它們將用於間接執行攻擊者的shellcode。

Answer 2

嗯，事實上，在一個緩衝區溢出攻擊，可以插入惡意代碼，而重寫RET指針。您無需爲此修改任何內容，因此作爲結論，我無法看到兩種攻擊之間的區別。

例如：

char* str[5];
cin << str;

這是可以exploided，如果用戶將一個字符串大於5個字符，一切下面將被覆蓋在堆棧上的代碼。由於ret-ptr在堆棧中「較低」的事實，如果距離正確，則可以覆蓋它。重寫時你的意圖是讓它指向輸入的開始，在其中插入惡意（彙編程序）代碼，只要調用ret-ptr並執行「跳轉」就會執行代碼。

Answer 3

重寫保留地址的該部分的攻擊兩者之間共享。正如上面的答覆所表明的那樣，您以前只是簡單地返回到您編寫的彙編代碼中。然後這個彙編代碼就會產生一個root用戶shell。

在這兩次攻擊中，你都不會'覆蓋'源代碼。從程序集的角度來看，源代碼位於.text段，並且一直（或至少在我知道的時候）受寫保護。你曾經使用過的東西是編寫你已經組裝到內存段中的代碼，然後跳轉到這段代碼。代碼最通常位於「堆棧段」中或附近，並且通過溢出所選擇的任何內容，您將重定向來自ret地址（例如）的流量。其他攻擊場所包括一個你事先創建並填充你的shellcode的環境變量;或者也是堆，函數指針或PLT。這樣插入的代碼通常會使用system（）調用來執行所期望的操作 - 但是爲此，您需要能夠在內存區域執行（或者將您打算使用的重定位條目聲明爲可寫）。

的兩次攻擊之間的區別在於，一旦內存已經取得了很大程度上的非可執行文件，攻擊類型（堆棧溢出）是非常擰。當你寫作時，試圖繞過這種類型的攻擊直接訪問共享庫函數 - 也就是說，你不再需要將代碼先寫入堆棧段或其他地方，然後在那裏執行。不過，我認爲libc類型的攻擊現在也已基本修補;我沒有這方面的細節。也許我錯了。

如果您想了解這些攻擊如何受到阻礙，或者至少閱讀了一些關鍵想法，谷歌「2011年粉碎堆棧」（或2010年）開始。

Answer 4

我想說緩衝區溢出是一類編程錯誤和返回到libc是一個漏洞利用技術。最好不要將這些概念混合在一起。

例如，你可以使用返回到libc利用一個緩衝區溢出漏洞。或者你也可以使用其他技術，如回報與.text區段，或回的shellcode。反之，你也可以使用返回到libc利用其他錯誤，如格式字符串了。