当前位置：首页 > article >正文

GNU Screen 曝多漏洞：本地提权与终端劫持风险浮现

article 2025/9/27 16:37:19

GNU Screen漏洞setuid-root提权示意图

SUSE安全团队全面审计发现，广泛使用的终端复用工具GNU Screen存在一系列严重漏洞，包括可导致本地提权至root权限的缺陷。这些问题同时影响最新的Screen 5.0.0版本和更普遍部署的Screen 4.9.x版本，具体影响范围取决于发行版配置。

尽管GNU Screen是类UNIX系统中管理终端会话的核心工具，但研究显示其存在重大风险——特别是当Screen以setuid-root权限安装以支持多用户功能时。

关键漏洞分析

CVE-2025-23395：logfile_reopen()函数本地提权漏洞

最严重的漏洞允许本地权限提升。在Screen 5.0.0中，logfile_reopen()函数在重新打开用户定义的日志文件时未能正确丢弃提升的权限，使得攻击者可以向root所有的文件写入任意数据。

报告警告称："非特权用户可以在任意位置创建root所有的文件...所有写入Screen PTY的数据都将被记录到该文件中"。该漏洞可通过操纵日志文件的链接计数强制重新打开来触发，已在采用setuid-root方式安装Screen的Arch Linux和NetBSD系统上得到确认。

CVE-2025-46802：终端重连竞争条件漏洞

另一个重大缺陷涉及多用户会话重新连接时Attach()函数中的竞争条件。当被调用时，Screen会临时将终端设备模式设置为0666，使系统上任何进程都能读写用户的TTY。

SUSE表示："我们使用简单的Python脚本每两到三次尝试就能成功打开受影响的TTY"。虽然这种基于chmod的方法原本旨在实现会话守护进程间的通信，但却为击键拦截或命令注入创造了危险窗口。

CVE-2025-46803：默认全局可写PTY漏洞

Screen 5.0.0还将默认PTY模式改为0622，使其全局可写。这使得任何用户都能向Screen管理的PTY写入数据，重现了TTY劫持漏洞的部分特征——现在这已成为默认行为。除非明确覆盖编译时配置，否则Arch Linux和NetBSD等发行版都会受到影响。

其他安全缺陷

CVE-2025-46804：文件存在性信息泄露

通过滥用SCREENDIR环境变量，可诱骗Screen泄露root所有文件的存在及类型，揭示路径是目录、文件还是不可访问。

CVE-2025-46805：信号处理竞争条件

在对CVE-2023-24626的不完整修复中，Screen的信号发送逻辑仍存在竞争条件。攻击者可利用权限检查与实际信号发送之间的TOCTOU（检查时间/使用时间）窗口，向非目标进程发送SIGHUP或SIGCONT等信号。

strncpy()误用导致的缓冲区溢出

虽然未分配CVE编号，但Screen 5.0.0中存在一个不可利用的缓冲区溢出问题。当用户尝试向活动Screen会话发送含多个参数的命令时，可能导致崩溃。该问题源于用strncpy()不当替换strcpy()的行为，在启用FORTIFY_SOURCE保护的Arch Linux系统上已观察到崩溃现象。

受影响发行版

发行版	Screen版本	权限模型	受影响CVE
Arch Linux	5.0.0	setuid-root	CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804, CVE-2025-46805, 缓冲区溢出问题
NetBSD 10.1	-	setuid-root	同上
Fedora 42	5.0.0	setgid-screen	CVE-2025-46802(部分), 缓冲区溢出问题
FreeBSD 14.2	4.9.1	setuid-root	CVE-2025-46802, CVE-2025-46804, CVE-2025-46805
Gentoo	4.9.1/9999	setgid-utmp/setuid-root	CVE-2025-46802(部分), CVE-2025-46805(setuid-root配置下)
Debian 12.10	4.9.0	默认	CVE-2025-46802(部分)
Ubuntu 24.04.2	4.9.1	默认	CVE-2025-46802(部分)

安全建议

SUSE强烈建议现阶段不要以setuid-root权限安装Screen。报告指出，许多问题源于过时的权限管理模型和5.0.0版本代码重构期间引入的退步。

SUSE建议："Screen存在更广泛的设计问题：它始终以提升的权限运行，仅针对被认为危险的操作选择性丢弃权限。对于健壮的setuid-root程序，应该采用相反的方式：默认丢弃权限，仅在确实需要提升权限的操作时临时获取。"他们建议将多用户支持设为可选功能，可能限制为受信任组使用，并提出更广泛的架构变更以确保安全的权限处理。