1) 引言

Kea DHCP 发行版是 Internet Systems Consortium (ISC) 提供的下一代 DHCP 服务器套件。它取代了已经生命周期结束的传统 ISC DHCP 软件。

由于 SUSE 也将在其产品中提供 Kea DHCP，因此我们对它的代码库进行了例行审查。即使在检查 Kea 的网络安全性之前，我们就发现了一系列本地安全问题，其中包括在许多 Linux 和 BSD 发行版的默认 Kea 安装中可能出现的本地 root 漏洞。下面将详细报告这些问题以及其他一些问题和 Kea 的安全建议。

本报告基于 Kea 2.6.1 版本。本报告中所有的源代码引用都与此版本相关。许多系统仍在使用旧版本的 Kea，但我们认为它们也都受到本报告中所述问题的威胁。

在下一节中，将提供 Kea 设计的概述，只要它与本报告中的问题相关。在第 3 节中，将详细讨论我们发现的安全问题。在第 4 节中，将提供进一步的加固建议。在第 5 节中，将讨论 upstream 的 Bug 修复。在第 6 节中，将记录 Kea 在广泛使用的 Linux 和 UNIX 系统上的打包属性和受影响情况。最后在第 7 节中，将提供 CVE 分配的概述。

2) Kea 设计概述

本节提供了一个相关的组件的简要概述，以便让不熟悉 Kea 的读者更好地理解本报告的其余部分。

Kea 提供三个独立的 dhcp4、dhcp6 和 dhcp-ddns 服务。在大多数 Kea 安装中，默认会有一个 kea-ctrl-agent 运行，并提供一个监听在 localhost:8000 上的 HTTP REST API。此 REST API 基于 JSON 请求，这些请求由 kea-ctrl-agent 本身处理，或转发给它控制的 Kea 服务之一。为了实现转发，每个 Kea 服务都监听一个仅对 kea-ctrl-agent 可访问的 UNIX 域套接字。

在大多数安装中，REST API 默认对系统中的所有用户都可访问，无需身份验证。许多安装以完全 root 权限运行 Kea 服务。在那些使用专用服务用户帐户的 Linux 系统上，CAP_NET_BIND_SERVICE Linux 功能被分配给所有 Kea 服务。dhcp4 服务此外还需要 CAP_NET_RAW 才能运行。

Kea 的默认配置和打包是判断本报告中所述问题可利用性的重要方面。从某种意义上说，这些问题可以被认为是供应商特定的问题，而不是 upstream 问题（当我们首次报告这些问题时，一些 ISC 工程师倾向于这样认为）。然而，受影响的 Kea 包的数量以及 Kea 构建系统安装的默认配置也启用了未经身份验证的 REST API，这使得这些问题看起来像是普遍的 upstream 问题。

3) 安全问题

3.1) 通过 set-config 命令注入 Hook 库导致本地权限升级 (CVE-2025-32801)

set-config REST API 命令允许完全控制 kea-ctrl-agent 本身以及各个 Kea 服务的配置。通过配置一个不受特权用户控制的 hook 库，可以实现一个简单的本地权限升级。以下示例使用 curl 工具来执行此漏洞利用。

someuser$ curl -X POST -H "Content-Type: application/json" \
    -d '{ "command": "config-set", "arguments":
          { "Control-agent": {"hooks-libraries": [{"library": "/home/someuser/libexploit.so"}] }}}' \
    localhost:8000

通过在 libexploit.so 中放置一个构造函数，攻击者控制的代码将在 kea-ctrl-agent 在 dlopen() 加载库时被执行。在运行 Kea 服务作为 root 的安装中，其影响是任意代码执行，具有完全的 root 权限。在那些使用专用服务用户为 Kea 的系统上，其影响将是对 Kea 进程的完全控制以及提升的网络权限。

Hook 库也可以为任何其他 Kea 服务配置，因此可以通过这种方式在每个 Kea 守护进程的上下文中实现代码执行。

我们提供了一个简单的 Python 脚本 kea-hook-lib-exploit.py 可供下载，用于重现此问题。

3.2) 通过 config-write 命令任意覆盖文件 (CVE-2025-32802)

config-write REST API 命令指示 Kea 服务将其配置写入任意文件路径

curl -X POST -H "Content-Type: application/json" \
    -d '{ "command": "config-write", "arguments": { "filename": "/etc/evil.conf" } }' \
    localhost:8000

文件写入是通过一个标准的 C++ std::ofstream 完成的，并带有 trunc 设置，即目标文件将被截断并覆盖（如果它已存在）。写入磁盘的配置内容也可以由攻击者控制，但 Kea 强制执行的 JSON 格式和配置健全性检查限制了最终写入内容的自由度。

如果 Kea 服务以完整的 root 权限运行，那么这将是一个本地拒绝服务，接近于本地 root 漏洞。通过嵌入 shell 代码，一个经过精心构造的 JSON 配置（例如写入 /etc/profile.d 中的文件）可以在 root 登录时触发本地 root 漏洞。

如果 Kea 服务以专用的服务用户身份运行，那么此攻击向量可用于损坏 Kea 拥有的配置、日志和状态文件，从而导致完整性被破坏和服务拒绝，但仅限于 Kea 服务范围。

3.3) 日志文件重定向到任意路径 (与 3.2 共享 CVE)

这与问题 3.2 类似：可以配置 Kea 服务使用任意新的日志文件路径。这是一个演示该问题的 JSON 配置示例

{
    "command": "config-set",
        "arguments": {
             "Control-agent": {
                 "loggers": [{
                     "name": "kea-ctrl-agent",
                     "output-options": [{
                         "output": "/root/bad.log"
                     }],
                     "severity": "DEBUG"
                 }]
             }
         }
     }
}

此配置会导致 kea-ctrl-agent 创建文件 /root/bad.log，并将日志级别设置为 DEBUG，可能暴露敏感的内部程序状态。此外，还将创建一个锁定文件 /root/bad.log.lock。

此攻击向量带来了另一个本地拒绝服务漏洞，接近于第 3.2 节中所述的本地 root 漏洞。

3.4) /tmp 中使用套接字的服务欺骗 (与 3.2 共享 CVE)

为了将 REST API 请求转发给 Kea 服务之一，kea-ctrl-agent 会尝试连接到该服务的 UNIX 域套接字。如果一个合法的 Kea 管理员试图向一个当前未运行的 Kea 服务（例如 kea-dhcp-ddns 服务，该服务在大多数发行版中并非默认配置）发送命令，那么该管理员可能会成为本地服务欺骗攻击的受害者。

这是否可能取决于 UNIX 域套接字放置的目录。许多发行版都使用公共的 /tmp 目录。在这种情况下，一个不受特权限制的本地用户可以自行创建一个用户需要的 UNIX 域套接字，例如在 /tmp/kea-ddns-ctrl-socket。如果成功，API 请求将被转发到一个欺骗服务，该服务可以响应一个精心构造的回复。利用这一点，本地攻击者可以尝试诱使用户管理员执行危险操作，或者可能能够拦截转发给欺骗服务的请求中包含的敏感数据。

例如，我们在 Fedora 41 上重现了此攻击向量

curl -X POST -H "Content-Type: application/json" \
    -d '{ "command": "config-get", "service": [ "d2" ], "arguments": { "secret": "data" } }' \
    localhost:8000

d2 服务套接字在 kea-ctrl-agent 中是默认配置的，并且指向 kea-dhcp-ddns 服务。当在 kea-ctrl-agent 上运行 strace 时，在执行此请求期间观察到以下 connect() 尝试

connect(18, {sa_family=AF_UNIX, sun_path="/tmp/kea-ddns-ctrl-socket"}, 27) = -1 ENOENT (No such file or directory)

本地无特权用户可以在 /tmp/kea-ddns-ctrl-socket 中绑定一个 UNIX 域套接字来拦截任何此类请求。

这种攻击类型还会影响已经配置但尚未运行的 Kea 服务，例如在 Kea 服务单元或 init 脚本启动之前，或者当 Kea 服务重新启动时。启动时，每个服务都会尝试 unlink() UNIX 域套接字路径，然后再绑定到它，但这会受到一个竞争条件的影响，无特权用户可以通过在合法服务有机会这样做之前在该位置重新绑定套接字来赢得该竞争。合法服务将无法启动，而无特权用户将能够拦截 kea-ctrl-agent 转发给欺骗服务的 REST API 请求。

3.5) /tmp 中使用套接字导致拒绝服务问题 (与 3.2 共享 CVE)

为 Kea 服务套接字使用 /tmp 目录通常是有问题的。Kea 服务会在套接字目录中创建基于套接字名称的锁定文件。任何本地用户都可以预先创建 UNIX 域套接字或相关的锁定文件，以阻止 Kea 服务启动。

3.6) /var/lib/kea/*.cvs 中可被所有人读取的 DHCP 租约文件 (CVE-2025-32803)

我们检查的许多发行版都允许读取默认 Kea 内存数据库的状态数据，该数据库在大多数情况下位于 /var/lib/kea。这意味着所有本地用户都能够访问此信息，从而构成本地信息泄露。DHCP 租约是否属于私有数据是有争议的。然而，更敏感的数据可能存储在这些文件中（在未来的实现中）。

我们不建议允许对此数据进行普遍的读取访问。最初我们仅将此报告为加固建议，但 upstream 仍决定为此分配 CVE。

3.7) 可被所有人读取的 Kea 日志文件 (与 3.6 共享 CVE)

在我们检查的大多数系统中，位于 /var/log/kea 或 /var/log/kea*.log 的 Kea 日志文件是可被所有人读取的。作为加固措施，我们建议限制对此数据的访问。

最初我们仅将此报告为加固建议，但 upstream 仍决定为此分配 CVE。

4) 加固建议

本节包含进一步的加固建议，涉及我们目前不认为具有高严重性的问题。

4.1) HTTP Basic Auth 实现可能存在的时序攻击

kea-ctrl-agent 使用 HTTP Basic Auth 机制来实现 REST API 接口上的身份验证。在此方案中，字符串 "<username>:<password>" 被 base64 编码并放入 "Authorization:" HTTP 标头。

这些凭据的验证发生在 BasicHttpAuthConfig::checkAuth() 中。代码维护一个 std::unordered_map<std::string, std::string>，其中键是 Kea 配置中找到的 base64 编码的 "<username>:<password>" 组合。值是可以通过键中的凭据进行身份验证的明文用户名。

在 basic_auth_config.cc:365 中，REST API 客户端提供的凭据直接在此映射数据结构中查找以进行验证。明文密码的验证在使用优化的字符串比较例程进行比较时，可能会遭受时序攻击的弱点。攻击者可以通过统计服务报告身份验证失败所需的时间，一点一点地构建一个有效的用户名/密码组合。

在 kea-ctrl-agent 的情况下，比较的不是明文密码，而是 base64 编码的 "<username>:<password>" 字符串。这增加了一些复杂性，但并没有阻止时序攻击的成功。然而，使用 std::unordered_map 是一个更大的障碍，它使用哈希函数来查找映射中的元素。当使用 gcc 编译器套件和 libstdc++ 标准库时，std::string 的默认哈希函数是 MurmurHash2，具有一个静态种子。虽然哈希查找使时序攻击变得复杂，但它仍然是一个确定性算法，攻击者可以选择输入值，以使 kea-ctrl-agent 为哈希映射查找生成适合时序攻击的哈希值。

为了安全起见，我们建议为 std::unordered_map 提供一个自定义的 KeyEqual 模板参数。这个键比较函数应该实现一个常数时间比较，以避免任何可观察到的时间差异。

鉴于目前的情况，这种时序攻击的复杂性非常高，我们目前不认为这是一个相关的安全问题。然而，有针对性的攻击者可能愿意尝试并成功。

4.2) 通过 ‘get-config’ 命令泄露 API 凭证

当 REST API 中启用了 API 授权时，配置可能包含用于身份验证的明文用户名和密码。拥有有效凭据的用户可以通过 API 检索配置来发现其他用户的凭据，即使该配置文件在系统中通常不可被所有人读取。

这意味着任何拥有有效凭据的用户都可以冒充任何其他用户。当某个用户的凭据被吊销时，这也可能成为一个问题。通过存储其他用户的凭据，即使在被拒绝访问 Kea 后，这样的用户仍然可以访问 API。另一个问题是用户可能在其他不相关的服务中重复使用相同的凭据。

不应在 API 级别暴露明文凭据，除非客户端是 root。即使那样，它也可能成为信息泄露的来源，例如，当管理员出于调试目的共享 Kea 配置转储时，却没有意识到数据中包含明文凭据。

Kea 用户可以通过避免在 Kea 配置中存储明文凭据，而是引用磁盘上的凭据文件（这些文件仅对特权用户可访问）来规避此问题。

5) Bug 修复

在我们最初的报告中，我们建议 upstream 限制加载 hook 库的路径（问题 3.1）以及写入配置和日志文件的路径（问题 3.2、3.3）。然而，未经身份验证的 REST API 显然存在比我们探索的具体利用场景更广泛的问题。系统中的任意用户不应能够完全控制 Kea 的配置。因此，我们建议默认强制执行 REST API 级别的身份验证。

为了修复本报告中描述的问题，upstream 发布了所有当前支持的 Kea 版本的错误修复版本

我们检查了 2.6.3 版本，并认为 Bug 修复是彻底的。正如 upstream 版本说明中所记录的，已引入以下更改

对于许多操作，只允许从安全目录读取或写入。其中涵盖了以下方面
- Hook 库只能从受信任的系统目录加载（解决问题 3.1）。
- 配置文件只能写入受信任的系统配置文件目录（解决问题 3.2）。
- 日志文件只能写入构建时确定的日志目录（解决问题 3.3）。
Kea 现在安装的默认配置文件强制执行 REST API 的身份验证。
日志、状态和套接字目录现在安装时没有全局可读/全局可写位（解决问题 3.5、3.6、3.7）。
套接字现在默认放置在 /var/run/kea 下。此目录不得全局可写（解决问题 3.5）。
文档和示例文件已更新，以避免出现本报告中讨论的问题。

第 4 节中讨论问题的加固措施尚未提供，但 upstream 计划在不久的将来解决。

6) Kea 配置在常见 Linux 和 UNIX 系统上的受影响情况

Kea 是一个跨平台项目，也面向传统的 UNIX 系统，这可能是没有成熟的 Kea 打包标准的缘由。每个发行版都以自己的方式集成 Kea，导致受影响情况的结果复杂多样。本节详细记录了各种当前知名的 Linux 和 BSD 系统上的默认设置和由此产生的受影响情况。

我们查看的所有系统都已于 2025-05-23 更新到最新的软件包版本。

6.1) Arch Linux


系统版本	滚动发行版（截至 2025-05-23）
Kea 版本	2.6.1
Kea 凭据	`root:root`
Kea 套接字目录	/tmp
Kea 日志目录	/var/log/kea-*.log, 权限 0644
Kea 状态目录	/var/lib/kea, 权限 0755
受影响情况	3.1 至 3.7

Arch Linux 受所有问题影响。

6.2) Debian Linux


系统版本	12.10, 12.11 (Bookworm)
Kea 版本	2.2.0
Kea 凭据	`_kea:_kea`
Kea 套接字目录	/run/kea, 所有者 `_kea:_kea` 权限 0755
Kea 日志目录	/var/log/kea, 所有者 `_kea:_kea` 权限 0750
Kea 状态目录	/var/lib/kea, 权限 0755
受影响情况	3.1 (部分), 3.2 (部分), 3.3 (部分), 3.6

当我们首次发现这些问题时，我们研究了 Debian 12.10。现已发布 Debian 12.11。不过，这两种版本的情况似乎相同。

由于服务以非 root 用户身份运行，因此此处不存在本地 root 漏洞。Debian 还为 Kea 服务应用了 AppArmor 配置文件。这使得 hook 库注入（3.1）变得困难。为了成功注入，需要一个攻击者可以写入并且 Kea 服务可以读取和映射库的目录。这似乎在 Kea 当前使用的 AppArmor 配置文件中不可能。因此，Debian 完全不受 3.1 的影响。

3.2) 和 3.3) 只会影响 _kea 拥有的且根据 AppArmor 配置允许写入的文件。这仍然允许破坏 _kea 拥有的日志、锁定和状态文件。

唯一的信息泄露存在于状态目录（3.6）中；日志受到保护。

AppArmor 安全

我们仔细检查了 Kea AppArmor 配置文件中是否存在漏洞，以使任意代码执行（3.1）成为可能。dhcp4、dhcp6 和 ddns Kea 服务的配置文件允许读取和映射 /home/*/.Private/** 中的文件，但有限制，文件必须由 _kea 所有。具有主目录的攻击者可以在其 $HOME/.Private/libexploit.so 中放置一个注入库。只有文件的所有权阻止了漏洞利用的成功。

利用问题 3.2），Kea 服务可以被指示在攻击者的 $HOME/.Private 中创建 _kea 拥有的文件。但是，创建的文件的内容并非完全由攻击者控制，因此无法以此方式构造一个有效的 ELF 对象供 dlopen() 加载。通过放置一个 setgid 目录在 $HOME/.Private/evil-dir，在该目录中创建的任何文件都将拥有攻击者的组所有权。然而，文件模式为 0644，因此攻击者仍然无法写入文件。我们的研究表明，在 Debian 的 _kea:_kea 上下文中，针对任意代码执行只剩下很薄的一层防御，但它似乎还能维持。

更新

Jakub Wilk 在 oss-security 邮件列表中分享了一个有效的攻击向量，使得绕过 AppArmor 限制成为可能。为了允许代码执行，可以为 $HOME/.Private 分配一个默认 ACL（访问控制列表）条目。

$ setfacl -d -m u:$LOGNAME:rwx ~/.Private/

在此目录中创建的新文件的模式是默认 ACL 设置与创建文件的程序使用的 mode 参数（在这种情况下，进程的 umask 不会被使用）的按位 AND。当使用 strace 观察时，Kea 创建配置文件的过程如下所示：

openat(AT_FDCWD, "/home/<user>/.Private/libexploit.so", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 14

结果是，Kea 创建的 libexploit.so 的模式将是 0666。虽然缺少可执行位，但 Linux 允许从没有可执行位的文件中 mmap() 可执行代码。这足以让 Kea 中的 dlopen() 成功并执行任意代码。实际的库代码可以直接重定向到 Kea 之前创建的 libexploit.so。

$ cat /path/to/librealexploit.so >~/.Private/libexploit.so

利用代码仍然会受到应用于 Kea 进程的 AppArmor 配置文件的限制。这意味着，例如，只能修改 AppArmor 配置文件允许写入的文件。这仍然使得控制磁盘上的所有 Kea 状态成为可能。

6.3) Ubuntu Linux


系统版本	24.04.02 LTS
Kea 版本	2.4.1
Kea 凭据	`_kea:_kea`
Kea 套接字目录	/run/kea, 所有者 `_kea:_kea` 权限 0755
Kea 日志目录	/var/log/kea, 所有者 `_kea:_kea` 权限 0750
Kea 状态目录	/var/lib/kea, 权限 0755
受影响情况	3.6

Ubuntu 在很大程度上等同于 Debian Linux 的情况，但有一个主要区别：REST API 访问身份验证通过配置自定义的“用户:密码”对或生成随机密码来强制执行。如果未配置密码，kea-ctrl-agent 将不会启动。

因此，Ubuntu 完全不受 3.1 和 3.2 的影响。只存在状态目录中的信息泄露（3.6）。

6.4) Fedora Linux

	Fedora 41	Fedora 42
Kea 版本	2.6.1	2.6.2
Kea 凭据	`kea:kea`	”
Kea 套接字目录	/tmp	”
Kea 日志目录	/var/log/kea, 权限 0755	/var/log/kea, 权限 0750
Kea 状态目录	/var/lib/kea, 权限 0750	”
受影响情况	(均限于 `kea:kea` 凭据) 3.1, 3.2, 3.3, 3.4, 3.5, 3.7	(均限于 `kea:kea` 凭据) 3.1, 3.2, 3.3, 3.4, 3.5

当我们首次发现这些问题时，我们研究了 Fedora 41。现已发布 Fedora 42。Fedora 42 中发现了一些变化，其中最显著的是 /var/log/kea 的更安全模式。

由于服务以非 root 用户身份运行，因此 Fedora 不存在本地 root 漏洞。

第 3.1 和 3.2 项仅影响 Kea 的完整性以及 CAP_NET_RAW 和 CAP_NET_BIND_SERVICE 功能的升级。Kea 没有 SELinux 策略生效，因此不存在阻止在 kea:kea 上下文（3.1）中执行任意代码的额外保护层。

Fedora 在 kea:kea 凭据的限制下，受到 3.3、3.4 和 3.5 的影响。在 Fedora 41 中，日志目录（3.7）存在信息泄露。两个版本的 Fedora 的状态目录都是安全的。

6.5) Gentoo Linux


系统版本	滚动发行版（截至 2025-05-23）
Kea 版本	2.4.1
Kea 凭据	`root:root`
Kea 套接字目录	/run/kea, 所有者 `dhcp:dhcp` 权限 0750
Kea 日志目录	/var/log/kea, 所有者 `root:dhcp` 权限 0750
Kea 状态目录	/var/lib/kea, 所有者 `root:dhcp` 权限 0750
受影响情况	如果 `kea-ctrl-agent` 被手动启用：3.1, 3.2, 3.3

在 Gentoo Linux 上，Kea 仅作为不稳定的 ~amd64 ebuild 可用。它似乎仍不完整，因为默认配置是错误的（路径错误），服务也无法启动。此外，kea-ctrl-agent 不包含在默认配置中。

目录权限与 Kea 服务运行的 root:root 凭据不一致。这为被破解的 dhcp 用户/组在 /run/kea 中进行符号链接攻击提供了机会。

没有信息泄露，并且 /tmp 目录未用于套接字。由于代理程序根本不作为默认配置，我们认为 Gentoo 不受任何问题的影响。

如果 kea-ctrl-agent 被主动添加到环境中且 REST API 未启用授权，那么 Gentoo 将受到 3.1、3.2 和 3.3 问题的影响。

6.6) openSUSE Tumbleweed

系统版本	滚动发行版（截至 2025-04-01）	滚动发行版（截至 2025-05-23）
Kea 版本	2.6.1	2.6.2
Kea 凭据	`root:root`	`keadhcp:keadhcp`
Kea 套接字目录	/tmp	/tmp
Kea 日志目录	/var/log/kea, 所有者 `keadhcp:keadhcp` 权限 0755	模式更改为 0750
Kea 状态目录	/var/lib/kea, 所有者 `root:root` 权限 0755	/var/lib/kea, 所有者 `keadhcp:keadhcp` 权限 0750
受影响情况	3.1 至 3.7	(均限于 keadhcp 凭据) 3.1, 3.2, 3.3, 3.4, 3.5

当我们首次发现这些问题时，openSUSE Tumbleweed 完全受到所有这些问题的影响。在这些问题发布之前，我们请 Kea 维护者对其打包进行加固，这可以在不泄露漏洞信息的情况下完成。在 openSUSE Tumbleweed 上当前的 Kea 打包中，Kea 不再以 root 身份运行，并且 systemd 单元已启用 ProtectSystem=full，这增加了另一层防御。 /var/log/kea 和 /var/lib/kea 中的信息泄露也已得到修复。

更具破坏性的更改已被推迟到这些问题的普遍发布，并将尽快得到解决。

6.7) FreeBSD


系统版本	14.2
Kea 版本	2.6.1
Kea 凭据	`root:root`
Kea 套接字目录	/tmp
Kea 日志目录	/var/log/kea-*.log, 所有者 `root:root` 权限 0644
Kea 状态目录	/var/db/kea, 所有者 `root:wheel` 权限 0755
受影响情况	3.1 至 3.7

FreeBSD 受所有问题影响。

6.8) NetBSD (pkgsrc 二进制包)


系统版本	10.1
Kea 版本	2.6.1
Kea 凭据	`root:root`
Kea 套接字目录	/tmp
Kea 日志目录	/var/log/kea-*.log, 所有者 `root:wheel` 权限 0644
Kea 状态目录	/var/lib/kea, 所有者 `root:wheel` 权限 0755
受影响情况	如果使用未修改的示例配置：3.1 至 3.7

NetBSD 支持安装 Kea 的 pkgsrc 二进制发行版，该发行版在 MacOS 等其他一些系统上也可用。此 Kea 发行版受所有问题影响。

但是，默认情况下没有激活任何配置。管理员必须将配置从 /usr/pkg/share/examples/kea 中的示例文件中复制过来。因此，NetBSD 是否受 Kea 默认安装的影响是有争议的。

6.9) OpenBSD


系统版本	7.6	7.7
Kea 版本	2.4.1	”
Kea 凭据	`root:root`	”
Kea 套接字目录	/var/run/kea, 所有者 `root:_kea` 权限 0775	”
Kea 日志目录	重定向到 syslog（全局可读）	”
Kea 状态目录	/var/lib/kea, 所有者 `root:_kea` 权限 0775	权限 0750
受影响情况	3.1, 3.2, 3.3, 3.6, 3.7	3.1, 3.2, 3.3, 3.7

当我们首次发现这些问题时，我们研究了 OpenBSD 7.6。现已发布 OpenBSD 7.7。据我们所知，只有 /var/lib/kea 目录的权限在此版本中有所改变。

OpenBSD 受 3.1、3.2 和 3.3 问题影响。套接字放置在专用目录中，因此 3.4 和 3.5 不适用。存在日志和状态数据（后者仅在 7.6 版本中）的信息泄露。

套接字和状态目录的 _kea 组所有权与实际守护进程凭据不一致。被破解的 _kea 组可以在这些目录中进行符号链接攻击。

7) CVE 分配

Kea upstream 分配了以下 CVE。其中一些是累积的，涵盖了本报告中发现的多个问题。

CVE	相关问题	描述
CVE-2025-32801	3.1	加载恶意 hook 库可能导致本地权限升级。
CVE-2025-32802	3.2, 3.3, 3.4, 3.5	不安全的文件路径处理允许多种本地攻击。
CVE-2025-32803	3.6, 3.7	不安全的文件权限可能导致敏感信息泄露。

时间线

2025-04-01	我们通过一个私有问题在 ISC GitLab 上报告了我们的发现。
2025-04-02	经过一些最初的争议性讨论后，Kea upstream 决定接受协调披露的提议并着手进行 Bug 修复。
2025-04-10	Upstream 分配了这些问题的 CVE。
2025-04-29	Upstream 传达了协调发布日期 2025-05-28，并表示他们打算提前 5 天通知 distros 邮件列表。考虑到受影响的发行版范围和问题的严重性，我们建议在发布前 10 天就通知 distros 邮件列表。
2025-05-15	Kea upstream 将漏洞预先披露给了 distros 邮件列表。
2025-05-22	Kea upstream 与 distros 邮件列表和私有 GitLab 问题共享了包含这些问题修复的私有错误修复版本 2.4.2、2.6.3 和 2.7.9 的链接。
2025-05-26	我们检查了版本 2.6.2 和 2.6.3 之间的差异，发现 Bug 修复是彻底的。
2025-05-28	发布按计划进行。

变更历史

2025-05-30

在第 6.2 节中添加了额外的攻击向量，以克服 Debian Linux 上的 AppArmor。修复了第 7 节中问题 3.3 遗漏的条目。

Kea DHCP：Linux 和 BSD 发行版的多个本地漏洞

目录