目录

1) 引言

lightdm-kde-greeter 是 lightdm 显示管理器的 KDE 主题登录器应用程序。9 月初，我们的一位社区打包人员要求我们审查 lightdm-kde-greeter 中包含的一个 D-Bus 服务，以将其添加到 openSUSE Tumbleweed 中。

在审查过程中，我们发现了一个潜在的权限升级问题，即 lightdm 服务用户可以通过此 D-Bus 服务提权至 root，此外还有其实现中的一些其他缺陷。

下一节提供了 D-Bus 服务的总体概述。第 3 节讨论了服务实现中的安全问题。第 4 节介绍了上游实现的错误修复。

本报告基于 lightdm-kde-greeter 版本 6.0.3。

2) D-Bus 辅助服务概述

lightdm-kde-greeter 包含一个 D-Bus 服务，该服务允许普通用户配置登录器应用程序使用的自定义主题。D-Bus 服务作为 KDE KAuth 辅助服务实现，以完全 root 权限运行。

该辅助服务实现了一个单一 API 方法，受 Polkit 动作 org.kde.kcontrol.kcmlightdm.save 保护，该动作默认要求 auth_admin_keep，即用户需要提供 root 凭据才能执行此操作。该方法接受一个键/值对映射，允许完全控制 lightdm.conf 和 lightdm-kde-greeter.conf 的内容。

从安全角度来看，这种通用接口并非最优，因为操作范围不限于更改主题设置，还允许更改 lightdm 的所有其他配置，从而降低了对系统中谁可以做什么的控制。然而，从应用程序的角度来看，这种方法是可以理解的，因为它使得支持任何未来功能变得容易。

另一个 Polkit 动作 org.kde.kcontrol.kcmlightdm.savethemedetails 在kcm_lightdm.actions 中声明，但未使用，可能是项目早期版本的遗留物。

3) D-Bus 辅助服务中的问题

D-Bus 服务中的问题始于helper.cc 第 87 行，我们可以在那里找到以下注释

// keys starting with "copy_" are handled in a special way, in fact,
// this is an instruction to copy the file to the greeter's home
// directory, because the greeter will not be able to read the image
// from the user's home folder

首先，滥用键/值映射（应包含配置文件条目）来传递“秘密”复制指令是一种相当糟糕的 API 设计。更糟糕的是，在 resulting 复制操作中混合了三种不同的安全上下文：

  • 以完全 root 权限运行的辅助服务。
  • 指定由辅助服务打开的路径的非特权 D-Bus 客户端。
  • lightdm 服务用户；辅助服务会将用户指定的文件复制到由其控制的目录中。

辅助服务以完整的 root 权限执行此复制操作，但未采取预防措施，从一个非特权上下文读取输入数据并将其写入另一个非特权上下文。这是使用 Qt 框架的 QFile::copy() 和类似 API 幼稚地完成的，导致了一系列潜在的本地攻击向量：

  • 拒绝服务（例如，将命名 FIFO 管道作为源文件路径传递，导致 D-Bus 辅助服务无限期阻塞）。
  • 信息泄露（例如，将私有数据路径作为源文件传递，如 /etc/shadow，然后它将公开在 /var/lib/lightdm 中）。
  • 在意外位置创建目录（辅助服务尝试创建 /var/lib/lightdm/.../<theme>，因此 lightdm 用户可以在那里放置符号链接，这些链接将被遵循）。
  • 覆盖意外文件（与之前类似，可以将符号链接作为目标文件名放置，这些链接将被遵循并用客户端数据覆盖）。

如果此操作被设置为 yes Polkit 身份验证要求，那么这将接近于本地 root 漏洞。即使以现有形式，它也允许 lightdm 服务用户将权限提升到 root。

有趣的是，这些问题与 sddm-kcm6 中的问题非常相似，我们在之前的博客文章中对此进行了介绍。

4) 上游错误修复

我们向上游提出了以下更改来解决这些问题：

  • 复制操作应使用 D-Bus 文件描述符传递来实现，这样就可以避免以 root 身份打开客户端控制的路径。
  • 为了在 lightdm 的目标目录中创建文件，应执行权限降级到 lightdm 服务用户，以避免任何符号链接攻击面。

我们很高兴地分享，lightdm-kde-greeter 的上游维护者密切遵循了我们的建议，并在错误修复发布之前与我们协调了更改。通过这些更改，这个 KAuth 辅助服务现在是一种模型实现，可以作为其他 KDE 组件的积极示例。上游还进行了一些通用清理，例如从存储库中删除了未使用的 savethemedetails Polkit 动作。

上游发布了 lightdm-kde-greeter 的版本 6.0.4，其中包含修复程序。

5) CVE 分配

经与上游协商，我们将 CVE-2025-62876 分配给本报告中描述的 lightdm 服务用户提权至 root 的问题。此问题的严重性较低，因为它仅影响深度防御（如果 lightdm 服务用户受到威胁），并且只有在特权用户交互式触发时才能达到和利用该有问题的逻辑。

6) 协调披露

我们于 2025 年 9 月 4 日向 KDE 安全部门报告了这些问题，并提议进行协调披露，但我们最初在与他们建立流程时遇到困难。上游没有明确表达进行协调披露的愿望，无法设定（初步）发布日期，也未收到问题的确认。

当 lightdm-kde-greeter 的一位开发人员于 2025 年 10 月 16 日直接联系我们并讨论发布日期和修复程序时，情况有所好转。我们认为随后的错误修复审查过程非常有帮助，极大地改进了 lightdm-kde-greeter 中的 KAuth 辅助服务实现。

7) 时间线

2025-09-04 我们收到了 lightdm-kde-greeter D-Bus 服务的审查请求。
2025-09-10 我们私下向 KDE 安全部门报告了调查结果。
2025-09-17 我们收到了 KDE 安全部门的初步回复，称他们会回复我们。
2025-09-29 我们要求至少确认报告并给出大致披露日期，但上游未能提供。
2025-10-01 KDE 安全部门通知我们，上游开发人员计划在 11 月中旬发布修复程序。
2025-10-16 一位上游开发人员联系我们讨论发布日期，因为错误修复已准备就绪。
2025-10-20 我们请开发人员分享错误修复以供审查。
2025-10-21 开发人员与我们分享了一组补丁。
2025-10-24 我们同意 2025 年 10 月 31 日作为协调披露日期。
2025-10-28 经过几次关于补丁的电子邮件交流后，上游得到了一组改进的补丁。我们建议为 lightdm 到 root 的攻击面分配一个 CVE。
2025-10-29 我们分配了 CVE-2025-62876。
2025-11-03 我们询问了错误修复版本何时发布，因为披露日期已过。
2025-11-03 上游同意在同一天发布。
2025-11-03 上游发布了包含错误修复的 版本 6.0.4。我们发布了关于此主题的Bugzilla 错误报告。
2025-11-13 本报告发布。

8) 参考资料