代碼漏洞

Question

作為一項學習練習，我試圖在下面的代碼片段中找到一個弱點，以便以可執行文件的所有者身份獲得訪問權限。

setresuid(geteuid(), geteuid(), geteuid());
system("/usr/bin/id");

FWIW，我什么都看不到。 我知道setresuid會將uid設置為文件的所有者，但是我不能將所有者更改為除我之外的任何人。 我曾考慮過嘗試通過更改PATH來重定向id命令，但是由於它使用了絕對路徑，因此該技巧不起作用。 提示？

Answer 1

有可能利用一個晦澀（現已修補）的問題，該問題涉及對setresuid()的未經檢查的使用：

1. 在Linux 2.6和更高版本中，如果進程使用RLIMIT_NPROC （即，對由ulimit -n設置的進程數的限制）運行，則setresuid()可能會失敗 ，從而使得如果setresuid() ，目標UID會有太多進程setresuid()成功。

   但是，在Linux 3.1和更高版本中，如果setresuid()失敗， setresuid()在進程上設置一個標志，以使任何后續execve()調用都將失敗。 如果setresuid()失敗，這將阻止system()在任何現代Linux上運行。

2. 除非有一些較大的上下文被忽略，否則可能會設置環境變量（例如LD_PRELOAD ），從而導致代碼被注入到/usr/bin/id 。 這些變量對於setuid可執行文件將被忽略，但對於setuid可執行文件啟動的可執行文件將不會被忽略，就像在這里發生的那樣。

如果您使用的是易受攻擊的系統（Linux 2.6至3.0），則可以通過設置環境變量並導致setresuid()失敗來利用此漏洞，以便/usr/bin/id以root用戶/usr/bin/id運行用戶指定的代碼。

Answer 2

system()函數通過將參數傳遞給/bin/sh -c來執行作為其參數給出的命令。 我認為/usr/bin/id程序不是特別重要； 關鍵是外殼的行為。 特別要注意的是，當實際UID和有效UID不同時，shell的啟動行為也不同：

如果shell以有效用戶（組）ID不等於真實用戶（組）ID的身份啟動，則不會讀取啟動文件，也不會從環境，SHELLOPTS，BASHOPTS，CDPATH，和GLOBIGNORE變量（如果它們出現在環境中）將被忽略，並且有效用戶ID設置為實際用戶ID。

-BASH 4.1手冊

如果包含您提供的代碼的程序已安裝suid，則該代碼會通過設置所有等於有效UID（將是所有者的UID）的實際，有效和保存的UID來防止應用該段中給出的條件可執行文件）。

攻擊通常圍繞不安全地使用不可靠的數據，而環境變量常常是違法者。 ENV環境變量特別命名一個文件，該文件在某些​​情況下將在啟動時執行。 如上面摘錄中所述，當實際UID與有效UID不同時， bash不會運行它，但在POSIX兼容模式下以交互方式或以sh調用時， bash不會運行它。

如此處適用的那樣，這對於非交互式調用沒有幫助，所以現在我不得不進行推測。 我懷疑 ，但目前無法記錄，以非交互方式調用時，shell的其他某些版本（甚至可能是當前版本） 確實會從ENV命名的文件中讀取並執行命令。 這將提供一個向量來作為setuid程序的所有者執行任意命令。

在這種推測的弱支持下，我將您的注意力轉向BASH_ENV變量，該變量類似於ENV ，但在非交互調用bash時（如bash ）使用該變量。 我假設一旦這兩個變量更加並行，就適用於交互式和非交互式模式，但是在不同時間刪除了ENV的非交互式使用和BASH_ENV的交互式使用。 由於不同的原因。 很可能刪除了ENV的非交互式使用，以准確塞住您要查找的孔。