Linux系統systemd-journald服務本地提權漏洞怎么修復

本篇內容介紹了“Linux系統systemd-journald服務本地提權漏洞怎么修復”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

0x00 摘要

Qualys安全公司在systemd-journald中發現了3個漏洞

• CVE-2018-16864、CVE-2018-16865：內存破壞

• CVE-2018-16866：信息泄露（越界讀）

Qualys安全公司表示，利用CVE-2018-16865 和 CVE-2018-16866 ，在10分鐘左右獲取了運行在i386體系結構上的Linux的root權限，在70分鐘左右獲取了運行在amd64體系結構上的Linux的root權限(該EXP未發布)。如果systemd以-fstack-clash-protection標志編譯，則漏洞無法利用(因為防止了堆棧沖突，通過下面的分析。就可以知道，漏洞利用的核心就是堆棧沖突)。

0x01 systemd-journald服務介紹

systemd-journald 是一個收集并存儲各類日志數據的系統服務。 它創建并維護一個帶有索引的、結構化的日志數據庫， 并可以收集來自各種不同渠道的日志：

• 通過 kmsg 收集內核日志

• 通過 libc 的 syslog接口收集系統日志

• 通過本地日志接口 sd_journal_print 收集結構化的系統日志

• 捕獲服務單元的標準輸出(STDOUT)與標準錯誤(STDERR)

• 通過內核審計子系統收集審計記錄

0x02 CVE-2018-16864

分析

函數

dispatch_message_real()（journal/journald-server.c）通過將每個字段轉換為格式為“=”的字符串來寫入日志。這些字符串是使用basic/string-util.h中定義的strjoina()函數構造的，其使用alloca()在棧上分配結果字符串。

如果攻擊者能夠通過構造較長的字符串，來使得棧與其他內存區域產生沖突，那么就有可能覆蓋其他區域的數據，導致崩潰或代碼執行。

在特殊的情況下，一個程序可能有一個很大的cmdline(可以通過/proc//cmdline讀取)造成堆棧沖突，從而造成systemd-journald崩潰或代碼執行。

利用

首先，從一個cmdline小的進程，發送一個大的、優先級高的消息給journald。這個消息強制一個大的寫 /var/log/journal/的操作(1MB與2MB之間)，并強制創建一個短暫的線程調用fsync等待從內存寫入磁盤的操作完成（重點：該線程的棧區域是在mmap區域中分配）

接下來，創建一些進程(32到64個)寫大文件（1MB -- 8MB）到 /var/tmp/中.這些進程使得journald中調用fsync的線程能夠存活更久，讓我們更能容易利用該漏洞。

最后，通過一個進程發送一個小的，低優先級的消息到journald。其cmdline非常大的（128MB左右，為棧區與 mmap 區域的距離），使得調用alloca()函數時，能夠覆蓋掉journald中調用fsync()線程的棧空間，從而造成代碼執行。

0x03 CVE-2018-16865

分析

journal-file.c中的journal_file_append_entry()函數通過alloca()分配一個EntryItem結構數組,其條目數可以由本地攻擊者控制。

通過直接訪問UNIX域套接字（默認位于/run/systemd/journal/socket），攻擊者可以向套接字發送許多條目，從而使得 alloca() 函數分配EntryItem結構數組覆蓋其他內存區域。進而造成systemd-journald崩潰或權限提升。

利用

首先跳躍到libc的讀寫段并覆蓋一個函數指針。但是這并不簡單，從“for”循環（在journal_file_append_entry（）中）調用的函數可能會破壞掉在目標函數指針下方的字節， 因此會覆蓋可能崩潰或死鎖的重要libc變量。因此，我們有時必須稍微改變我們的alloca()跳躍，以避免覆蓋這些重要變量。

我們想用另一個函數或ROP鏈的地址覆蓋我們的目標函數指針，但不幸的是，在“for”循環中調用的函數的棧幀（在journal_file_append_entry（）中）不包含我們控制的任何數據。但是，寫入alloca（）ted“items”的64位“哈希”值是由jenkins_hashlittle2（）生成的，這是一個非加密哈希函數：我們可以很容易地找到一個短字符串哈希到指定值（將覆蓋我們的目標函數指針的地址），也是valid_user_field（）（或journal_field_valid（））。

為了完成我們的利用，我們需要journald的棧指針，以及libc讀寫段中目標函數指針的地址，因此我們需要一個信息泄露漏洞。

0x04 CVE-2018-16866

分析

journald-syslog.c中的syslog_parse_identifier()函數沒有正確解析以":"結尾的日志字符串，返回超出原始字符串限制的指針。從而使得攻擊者可以利用該漏洞泄露systemd-journal進程的內存地址。

利用

從journald泄漏堆棧地址或mmap地址：

首先，發送一個較大的本地消息到/run/systemd/journal/socket中;journald會調用mmap()，將我們的消息映射到內存，然后調用malloc()分配大量的iovec結構：大多數結構指向我們已經mmap()的消息，但是有少數指向棧（在 dispatch_message_real()）.iovec數組的內容在調用free()由heap hole保存（在journald 中處理完我們的消息后）

接下來，發送大量的syslog信息到/run/systemd/journal/dev-log;journald為了接受我們的大量消息，會調用realloc()從而獲取剛剛保存iovec數組的heap hole（其中仍然保存著mmap和棧指針）

最后，我們發送一個利用CVE-2018-16866的大型syslog消息： journald在其服務器緩沖區(在先前包含iovec數組的堆塊中)接收到大型消息，如果我們仔細選擇消息的大小，并將其結束符“:”放置在剩余的mmap或堆棧指針前面，然后我們可以泄漏這個指針（它被錯誤地解讀為我們信息的正文）

0x05 CVE-2018-16865 與 CVE-2018-16866的結合造成任意代碼執行

通過 CVE-2018-16866 我們可以獲得libc的地址，然后利用CVE-2018-16865我們可以改寫libc中的__free_hook函數指針為system函數的地址，從而造成任意代碼執行。

詳細過程參考資料4

0x06 影響版本

CVE-2018-16864 于 2013 年 4 月引入（systemd v203），并在 2016 年 2 月可利用（systemd v230）。

CVE-2018-16865 于 2011 年 12 月引入（systemd v38），在 2013 年 4 月可利用（systemd v201）。

CVE-2018-16866 于 2015 年 6 月引入（systemd v221），于 2018 年 8 月無意中被修復。

已知受影響的Linux 發行版有:Debian，Red Hat，Ubuntu。請自行查看自己系統中的systemd版本是否受影響。

“Linux系統systemd-journald服務本地提權漏洞怎么修復”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！