systemd-coredump 组件中发现了一个漏洞 (CVE-2022-4415)，该组件处理进程崩溃后生成的核心文件，允许非特权本地用户确定使用 suid root 标志运行的特权进程的内存内容。 默认配置问题已在 openSUSE、Arch、Debian、Fedora 和 SLES 发行版上得到确认。
该漏洞是由于未正确处理 systemd-coredump 中的 fs.suid_dumpable sysctl 参数造成的，该参数设置为默认值 2 时，允许为带有 suid 标志的进程生成核心转储。 据了解，内核写入的suid进程的核心文件必须设置访问权限，只允许root用户读取。 systemd-coredump 实用程序由内核调用来保存核心文件，它将核心文件存储在根 ID 下，但还根据最初启动进程的所有者的 ID 提供对核心文件的基于 ACL 的读取访问权限。
此功能允许您下载核心文件，而无需考虑程序可以更改用户 ID 并以提升的权限运行的事实。 该攻击归结为这样一个事实：用户可以启动 suid 应用程序并向其发送 SIGSEGV 信号，然后加载核心文件的内容，其中包括异常终止期间进程的内存切片。
例如，用户可以运行“/usr/bin/su”，并在另一个终端中使用命令“kill -s SIGSEGV `pidof su`”终止其执行，之后systemd-coredump会将核心文件保存在/ var中/lib/systemd/ 目录 coredump，为其设置允许当前用户读取的 ACL。 由于 suid 实用程序“su”将 /etc/shadow 的内容读取到内存中，因此攻击者可以访问有关系统上所有用户的密码哈希的信息。 sudo 实用程序不易受到攻击，因为它通过 ulimit 禁止生成核心文件。
据systemd开发人员称，该漏洞从systemd版本247（2020年246月）开始出现，但根据发现该问题的研究人员称，版本0也受到影响。如果systemd使用libacl库（默认在所有流行的发行版）。 该修复目前以补丁形式提供。 您可以在以下页面上跟踪发行版中的修复：Debian、Ubuntu、Gentoo、RHEL、SUSE、Fedora、Gentoo、Arch。 作为安全解决方法，您可以将 sysctl fs.suid_dumpable 设置为 XNUMX，这会禁止将转储发送到 systemd-coredump 处理程序。
来源： opennet.ru