TL博士。 在本文中，我們將探討在五個流行的 Linux 發行版上開箱即用的強化方案。 對於每一個，我們都採用預設的核心配置，載入所有套件，並分析附加二進位檔案中的安全方案。 考慮的發行版是 OpenSUSE 12.4、Debian 9、CentOS、RHEL 6.10 和 7，以及 Ubuntu 14.04、12.04 和 18.04 LTS。
結果證實，即使是堆疊金絲雀和位置無關程式碼等基本方案也尚未被所有人採用。 對於編譯器來說，在防止堆疊衝突等漏洞方面，情況更糟，該漏洞在 XNUMX 月發布後成為人們關注的焦點 。 但並非一切都那麼無望。 大量二進位檔案實現了基本的保護方法，並且其數量隨著版本的不同而增長。
審查顯示，Ubuntu 18.04 在作業系統和應用程式層級實現的保護方法數量最多，其次是 Debian 9。另一方面，OpenSUSE 12.4、CentOS 7 和 RHEL 7 也實現了基本的保護方案，以及堆疊衝突保護透過更密集的預設包集使用得更廣泛。
介紹
很難保證軟體的高品質。 儘管有大量用於靜態程式碼分析和動態執行時間分析的先進工具，並且編譯器和程式語言的開發取得了重大進展，但現代軟體仍然存在不斷被攻擊者利用的漏洞。 在包含遺留程式碼的生態系統中，情況甚至更糟。 在這種情況下，我們不僅面臨著尋找可能的可利用錯誤的永恆問題，而且還受到嚴格的向後相容性框架的限制，這通常要求我們保留有限的，甚至更糟糕的易受攻擊或有錯誤的代碼。
這就是保護或強化程序的方法發揮作用的地方。 我們無法阻止某些類型的錯誤，但我們可以讓攻擊者的日子變得更加困難，並透過阻止或預防來部分解決問題 手術 這些錯誤。 所有現代作業系統都使用這種保護，但這些方法在複雜性、效率和效能方面差異很大：來自堆疊金絲雀和 到全面保護 и 。 在本文中，我們將了解最受歡迎的 Linux 發行版在預設配置下使用的保護方法，並檢查透過每個發行版的套件管理系統分發的二進位檔案的屬性。
CVE 和安全性
我們都看過標題為「年度最脆弱的應用程式」或「最脆弱的作業系統」的文章。 通常他們提供有關漏洞的記錄總數的統計數據，例如 ， 從...獲取 從 和其他來源。 隨後，這些應用程式或作業系統根據 CVE 的數量進行排名。 不幸的是，雖然 CVE 對於追蹤問題以及通知供應商和用戶非常有用，但它們很少提及軟體的實際安全性。
例如，考慮過去四年來 Linux 核心和五個最受歡迎的伺服器發行版（即 Ubuntu、Debian、Red Hat Enterprise Linux 和 OpenSUSE）的 CVE 總數。
圖。 1
這張圖告訴我們什麼？ CVE 數量較多是否意味著一種發行版比另一種發行版更容易受到攻擊？ 沒有答案。 例如，在本文中，您將看到 Debian 比 OpenSUSE 或 RedHat Linux 等具有更強的安全機制，而 Debian 擁有更多的 CVE。 然而，它們並不一定意味著安全性減弱：即使存在 CVE 也並不表示漏洞是否存在 被剝削。 嚴重性分數顯示如何 大概 漏洞的利用，但最終的可利用性在很大程度上取決於受影響系統中的保護以及攻擊者的資源和能力。 此外，缺乏 CVE 報告並不能說明其他問題 未註冊或未知 漏洞。 CVE 的差異可能是由於軟體品質以外的因素造成的，包括分配給測試的資源或用戶群的規模。 在我們的例子中，Debian 的 CVE 數量較多可能只是表明 Debian 發布了更多的軟體包。
當然，CVE 系統提供了有用的信息，讓您可以創建適當的保護。 我們越了解程式失敗的原因，就越容易識別可能的利用方法並發展適當的機制 檢測和回應。 在圖中。 圖 2 顯示了過去四年中所有發行版的漏洞類別（）。 顯而易見，大多數 CVE 屬於以下類別：拒絕服務 (DoS)、程式碼執行、溢位、記憶體損壞、資訊外洩（滲透）和權限升級。 儘管許多 CVE 在不同類別中被多次計算，但總的來說，相同的問題年復一年地持續存在。 在本文的下一部分中，我們將評估使用各種保護方案來防止這些漏洞被利用。
圖。 2
任務
在本文中，我們打算回答以下問題：
- 不同Linux發行版的安全性如何？ 核心和用戶空間應用程式存在哪些保護機制？
- 隨著時間的推移，各發行版的安全機制的採用又發生了什麼樣的變化？
- 每個發行版的套件和函式庫的平均依賴性是多少？
- 每個二進位檔案實施了哪些保護？
分佈的選擇
事實證明，很難找到有關發行版安裝的準確統計數據，因為在大多數情況下，下載數量並不表示實際安裝數量。 然而，Unix 變體構成了大多數伺服器系統（在 Web 伺服器上佔 69,2%，按 W3techs 和其他來源），而且他們的份額正在不斷增長。 因此，在我們的研究中，我們將重點放在平台上開箱即用的發行版 。 我們特別選擇了以下作業系統：
發行版/版本
核心
建造
OpenSUSE 12.4
4.12.14-95.3-默認
#1 SMP 5 年 06 月 00 日星期三 48:2018:63 UTC 8 (29aXNUMXdXNUMX)
Debian 9（延伸）
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)
CentOS 6.10的
2.6.32-754.10.1.el6.x86_64
#1 SMP 15 年 17 月 07 日星期二 28:2019:XNUMX UTC
CentOS 7的
3.10.0-957.5.1.el7.x86_64
#1 SMP 1 年 14 月 54 日星期五 57:2019:XNUMX UTC XNUMX
紅帽企業 Linux 伺服器 6.10（聖地牙哥）
2.6.32-754.9.1.el6.x86_64
#1 SMP 21 年 15 月 08 日星期三 21:2018:XNUMX 美國東部時間
紅帽企業 Linux 伺服器 7.6（麥坡）
3.10.0-957.1.3.el7.x86_64
#1 SMP 15 年 17 月 36 日星期四 42:2018:XNUMX UTC
Ubuntu 14.04（值得信賴的塔爾）
4.4.0–140-通用
#166~14.04.1-Ubuntu SMP 17 月 01 日星期六 52:43:20 UTC XNUMX…
Ubuntu 16.04（Xenial Xerus）
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7 年 09 月 59 日星期五 47:2018:XNUMX UTC
Ubuntu 18.04（仿生海狸）
4.15.0–1026-gcp
#27-Ubuntu SMP 6 年 18 月 27 日星期四 01:2018:XNUMX UTC
表1
分析
讓我們研究預設的核心配置，以及透過每個發行版的套件管理器可用的套件的屬性。 因此，我們只考慮每個發行版預設鏡像中的軟體包，忽略來自不穩定儲存庫的軟體包（例如 Debian「測試」鏡像）和第三方軟體包（例如來自標準鏡像的 Nvidia 軟體包）。 此外，我們不考慮自訂內核編譯或安全強化配置。
內核配置分析
我們應用了基於的分析腳本 。 讓我們看看指定發行版的開箱即用保護參數，並將它們與來自的清單進行比較 （KSPP）。 對於每個配置選項，表 2 描述了所需的設定：此核取方塊適用於符合 KSSP 建議的發行版（有關術語的解釋，請參閱以下內容）。 ; 在以後的文章中，我們將解釋這些安全方法有多少種，以及在沒有這些方法的情況下如何破解系統）。
一般來說，新核心具有更嚴格的開箱即用設定。 例如，6.10 核心上的 CentOS 6.10 和 RHEL 2.6.32 缺乏較新核心中實現的大部分關鍵功能，例如 、嚴格的RWX權限、位址隨機化或copy2usr保護。 需要注意的是，表中的許多配置選項在舊版本的核心中不可用，並且在現實中不適用——這在表中仍然表明缺乏適當的保護。 同樣，如果給定版本中不存在配置選項，並且安全性要求禁用該選項，則這被認為是合理的配置。
解釋結果時要考慮的另一點是：一些增加攻擊面的核心配置也可用於安全性。 此類範例包括 uprobes 和 kprobes、核心模組以及 BPF/eBPF。 我們的建議是使用上述機制來提供真正的保護，因為它們使用起來並不簡單，而且它們的利用假設惡意行為者已經在系統中建立了立足點。 但如果啟用這些選項，系統管理員必須主動監控濫用情況。
進一步查看表 2 中的條目，我們發現現代核心提供了多種選項來防止利用漏洞，例如資訊洩漏和堆疊/堆疊溢出。 然而，我們注意到，即使是最近流行的發行版也尚未實現更複雜的保護（例如，使用補丁 ）或針對程式碼重複使用攻擊的現代保護（例如 ）。 更糟的是，即使這些更先進的防禦措施也無法抵禦全方位的攻擊。 因此，系統管理員必須透過提供運行時漏洞檢測和預防的解決方案來補充智慧配置。
應用分析
毫不奇怪，不同的發行版具有不同的套件特徵、編譯選項、庫依賴關係等。甚至對於 具有少量相依性的發行版和軟體包（例如 Ubuntu 或 Debian 上的 coreutils）。 為了評估差異，我們下載了所有可用的軟體包，提取其內容，並分析了二進位和依賴項。 對於每個包，我們追蹤它所依賴的其他包，對於每個二進位文件，我們追蹤它的依賴項。 在本節中，我們簡要地總結了結論。
發行版
我們總共為所有發行版下載了 361 個軟體包，僅從預設鏡像中提取軟體包。 我們忽略了沒有 ELF 可執行檔的包，例如原始碼、字型等。過濾後，剩下 556 個包，總共包含 129 個二進位檔案。 各發行版中包與文件的分佈如圖 569 所示。 584.
圖。 3
您可能會注意到，發行版越現代，它包含的套件和二進位就越多，這是合乎邏輯的。 然而，Ubuntu 和Debian 軟體包比CentOS、SUSE 和RHEL 包含更多的二進位檔案（包括執行檔和動態模組和函式庫），這可能會影響Ubuntu 和Debian 的攻擊面（應該注意的是，這些數字反映了所有版本的所有二進位檔案）包，即某些檔案被分析多次）。 當您考慮套件之間的依賴關係時，這一點尤其重要。 因此，單一套件二進位檔案中的漏洞可能會影響生態系統的許多部分，就像易受攻擊的程式庫可能會影響導入它的所有二進位檔案一樣。 首先，讓我們來看看不同作業系統中套件之間的依賴關係數量分佈：
圖。 4
在幾乎所有發行版中，60% 的套件至少有 10 個依賴項。 此外，某些套件的依賴項數量明顯較多（超過 100 個）。 這同樣適用於反向包依賴性：正如預期的那樣，發行版中的許多其他包使用了一些包，因此這些選定的少數包中的漏洞風險很高。 例如，下表列出了 SLES、Centos 20、Debian 7 和 Ubuntu 9 中反向依賴數量最多的 18.04 個軟體包（每個單元格表示軟體包和反向依賴數量）。
表3
有趣的事實。 儘管分析的所有作業系統都是針對 x86_64 架構構建的，並且大多數軟體包都將架構定義為 x86_64 和 x86，但軟體包通常包含其他架構的二進位文件，如圖 5 所示。 XNUMX.
圖。 5
在下一節中，我們將深入研究所分析的二進位檔案的特徵。
二進位檔案保護統計
至少，您需要為現有的二進位檔案探索一組基本的安全選項。 一些 Linux 發行版附帶了執行此類檢查的腳本。 例如Debian/Ubuntu就有這樣的劇本。 這是他的工作範例：
$ hardening-check $(which docker)
/usr/bin/docker:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yes該腳本檢查五個 :
- 位置無關可執行檔 (PIE)：指示如果在核心中啟用 ASLR，是否可以在記憶體中移動程式的文字部分以實現隨機化。
- 堆疊保護：是否啟用堆疊金絲雀以防止堆疊衝突攻擊。
- Fortify Source：不安全函數（例如，strcpy）是否替換為更安全的對應函數，運行時檢查的呼叫是否替換為其未檢查的對應函數（例如，memcpy 而不是 __memcpy_chk）。
- 唯讀重定位 (RELRO)：如果在執行開始之前觸發重定位表條目，是否將其標記為唯讀。
- 立即綁定：運行時連結器是否允許在程式執行開始之前進行所有移動（這相當於完整的 RELRO）。
上述機制是否足夠？ 很不幸的是，不行。 有一些已知的方法可以繞過上述所有防禦，但防禦越嚴格，攻擊者的門檻就越高。 例如， 如果 PIE 和立即綁定生效，則應用起來會更加困難。 同樣，完整的 ASLR 需要額外的工作來創建有效的漏洞。 然而，老練的攻擊者已經準備好滿足此類保護：他們的缺席將本質上加速駭客攻擊。 因此，這些措施必須被認為是必要的 最低限度.
我們想要研究相關發行版中有多少二進位檔案受到這些方法和其他三種方法的保護：
- 不可執行位（) 阻止在任何不應執行的區域執行，例如堆疊堆等。
- 表示動態載入器用來尋找符合庫的執行路徑。 第一個是 義務 對於任何現代系統：它的缺失允許攻擊者任意將有效負載寫入記憶體並按原樣執行。 對於第二個，不正確的執行路徑配置有助於引入不可靠的程式碼，從而導致許多問題（例如 和 ).
- 堆疊衝突保護可防止導致堆疊與其他記憶體區域（例如堆疊）重疊的攻擊。 鑑於最近的濫用行為 ，我們認為將該機制包含在我們的資料集中是合適的。
因此，事不宜遲，讓我們開始討論數字。 表 4 和表 5 分別包含各種發行版的可執行檔和函式庫的分析摘要。
- 如您所見，除了極少數例外，NX 保護隨處可見。 特別是，與 CentOS、RHEL 和 OpenSUSE 相比，它在 Ubuntu 和 Debian 發行版中的使用率略低。
- 堆疊金絲雀在許多地方都缺失，特別是在具有較舊核心的發行版中。 Centos、RHEL、Debian 和 Ubuntu 的最新發行版中已經看到了一些進展。
- 除了 Debian 和 Ubuntu 18.04 之外，大多數發行版對 PIE 的支援都很差。
- OpenSUSE、Centos 7 和 RHEL 7 中的堆疊衝突保護很弱，而在其他作業系統中幾乎不存在。
- 所有具有現代核心的發行版都對 RELRO 提供一定的支持，其中 Ubuntu 18.04 領先，Debian 緊隨其後。
如前所述，此表中的指標是二進位檔案所有版本的平均值。 如果您只查看文件的最新版本，數字將會不同（例如，請參閱 ）。 此外，大多數發行版在計算統計資料時通常只測試二進位檔案中少數函數的安全性，但我們的分析顯示了經過強化的函數的真實百分比。 因此，如果二進位檔案中的 5 個功能中有 50 個受到保護，我們會給它 0,1 分，這對應於 10% 的功能得到加強。
表 4. 圖 3 所示可執行檔的安全特性XNUMX（相關功能的實作佔可執行檔總數的百分比）
表 5. 圖 3 所示庫的安全特性XNUMX（相關功能實現量佔總庫總數的百分比）
那麼有進展嗎？ 肯定有：這可以從各個分佈的統計數據中看出（例如， ）以及上表的結果。 如圖所示。 圖 6 顯示了 Ubuntu LTS 5 三個連續發行版中保護機制的實作（我們省略了堆疊衝突保護統計）。 我們注意到，從一個版本到另一個版本，越來越多的檔案支援堆疊金絲雀，並且越來越多的二進位檔案附帶了完整的 RELRO 保護。
圖。 6
不幸的是，不同發行版中的許多可執行檔仍然沒有任何上述保護。 例如，查看 Ubuntu 18.04，您會注意到 ngetty 二進位檔案（getty 的替代品）、mksh 和 lksh shell、picolisp 解釋器、nvidia-cuda-toolkit 軟體包（GPU 加速應用程式的流行軟體包）例如機器學習框架）和klibc -utils。 同樣，mandos-client 二進位（一種管理工具，可讓您自動重新啟動具有加密檔案系統的電腦）以及rsh-redone-client（rsh 和rlogin 的重新實作）在發佈時沒有NX 保護，儘管它們具有SUID權限： （此外，一些 suid 二進位檔案缺乏基本的保護，例如堆疊金絲雀（例如，Xorg 套件中的 Xorg.wrap 二進位）。
總結和結束語
在本文中，我們重點介紹了現代 Linux 發行版的幾個安全功能。 分析表明，平均而言，最新的Ubuntu LTS 發行版(18.04) 在具有相對較新核心的發行版（例如Ubuntu 14.04、12.04 和Debian 9）中實現了最強的作業系統和應用程式層級保護。然而，所檢查的發行版CentOS、RHEL 和預設情況下，我們的集合中的OpenSUSE 會產生一組更密集的軟體包，並且在最新版本（CentOS 和RHEL）中，與基於Debian 的競爭對手（Debian 和Ubuntu）相比，它們具有更高百分比的堆疊衝突保護。 比較 CentOS 和 RedHat 版本，我們注意到從版本 6 到版本 7，堆疊金絲雀和 RELRO 的實作有了很大改進，但平均而言，CentOS 比 RHEL 實作了更多功能。 一般來說，所有發行版都應特別注意 PIE 保護，除了 Debian 9 和 Ubuntu 18.04 之外，我們資料集中不到 10% 的二進位檔案實現了 PIE 保護。
最後，應該指出的是，雖然我們手動進行研究，但有許多可用的安全工具（例如 , , ），它執行分析並幫助避免不安全的配置。 不幸的是，即使配置合理的強大保護也不能保證不被利用。 這就是為什麼我們堅信，確保 ，重點在於剝削模式並加以預防。
來源： www.habr.com