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服务本地提权漏洞怎么修复”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！