SSHole漏洞让Alpine上密码已禁用的账户可被直接登录

OpenSSH与musl C库在处理失败的密码哈希时存在一个已有十年历史的漏洞，远程攻击者只需发送一个长得离谱的密码，就能登录那些被刻意设置为无可用密码的账户。该漏洞编号为CVE-2026-123158，昵称为SSHole（或*sshole），CVSS评分为8.1，已在周四发布的紧急OpenSSH 10.6p2更新中修复。据CSO Online报道，该漏洞由安全测试公司Wakefield的研究员Ozgun Kultekin发现。

如果这个问题只出现在musl之外，它本可以只是一条脚注。但musl是Alpine Linux所用的C库，而Alpine这款极简发行版支撑着大量云端Docker镜像，还有一长串嵌入式系统。Alpine默认的OpenSSH构建开箱即满足该漏洞利用的所有条件，其官方云镜像还预置了一个密码已禁用的alpine用户，并拥有免密码的doas权限，一步即可提权至root。利用也并非纸上谈兵：威胁情报公司Previdian告诉The Hacker News，CVE发布后不到九小时，他们就观测到了首次攻击尝试，并在一台Alpine蜜罐上证实攻击者成功获得root权限。

原语：257个字符，内容随意

watchTowr威胁情报负责人Jake Knott在向CSO Online发表的评论中直言不讳：针对OpenSSH这样广泛使用的软件，漏洞利用说白了就是发送一个长密码，用一串A字符就行。他说，在受影响的系统上，整个技术手段就是一个长度在257到1024个字符之间的密码。

整个攻击就是这样。没有竞态条件，没有堆喷射，也没有shellcode。据Ars Technica报道，它只需一次连接，每次都能成功，无需重试。相比之下，2024年的regreSSHion是上一次OpenSSH的大型安全警报，它需要真正的漏洞利用工程能力；而SSHole只需要复制粘贴一串A。它唯一做不到的，是绕过真正的密码：正如The Hacker News指出的，该漏洞只对密码字段为星号的账户生效，因此拥有有效密码哈希的账户不受这一特定手法影响。

三个无害的改动，一个致命的星号

这个漏洞是三项相隔多年的改动在系统集成层面意外叠加的结果，每项单独看都站得住脚。2012年，musl的开发者将密码长度上限设为256字节，以防攻击者提交超大密码，耗尽服务器资源，因为每个密码都需要昂贵的哈希运算。同时，他们让musl的密码哈希函数在失败时返回一个星号（*），而这个字符自20世纪80年代起就是Unix用来标记“永远不应匹配任何密码”账户的符号。

2016年，OpenSSH修复了一个用户名枚举漏洞（CVE-2016-6210）。修复方式是：对于自身密码字段无可供哈希内容的账户，检查密码时借用另一个账户的盐值，目的是防止攻击者通过计时差异猜测有效用户名。之后在2022年，Alpine将root的密码字段改为星号，以便其SSH密钥登录继续可用。三者叠加，攻击链便自行形成：攻击者为一个密码已禁用的账户发送超过257字节的密码，musl的哈希尝试失败并返回*，sshd将其与账户密码字段中存储的*比对，两者匹配，大门就此敞开。

$ ssh alpine@target        # password: 300 x 'A'
# musl crypt() fails on >256 bytes -> returns "*"
# /etc/shadow stores "*" for the alpine account
# "*" == "*"  ->  sshd logs: Accepted password for alpine

需要说明的是，OpenSSH维护者认为问题不在自己的代码里，而在musl的错误处理上，但他们仍在10.6p2中加入了缓解措施。从防御者的角度看，互相推诿的意义远不如补丁本身重要。

哪些系统暴露，哪些不受影响

SSHole要生效必须同时满足以下五个前提条件，这份清单也可以直接当作你的排查范围清单：

• 发行版基于musl而非glibc，这一点排除了Debian、Ubuntu、Fedora以及大多数主流服务器发行版。
• SSH服务端是OpenSSH，而不是Dropbear之类的替代品（后者常见于嵌入式构建）。
• OpenSSH编译时未包含PAM支持，Alpine的标准软件包正是这样构建的。
• 启用了密码认证，这同样是Alpine的默认设置。
• 攻击者知道某个密码字段为星号的账户名，并且系统上至少存在一个拥有真实（SHA256/SHA512哈希）密码的账户。

Ars Technica指出的最后一个条件，对Alpine官方云镜像来说意味着一个棘手的问题。在3.18.11至3.24.3版本之间，这些镜像预置了密码已禁用的alpine账户及免密码的doas权限，但只有管理员为其他任何账户设置了密码之后，它们才会变得可被利用，因为借用盐值的代码路径需要一个拥有真实哈希的合法账户存在才能触发。只要有人完成这项日常的配置操作，镜像就会全面敞开，alpine登录会直接转为root。据Ars报道，其他基于musl的平台在相同配置下也可能受影响。Kultekin已在GitHub上发布了一个检测脚本，可识别暴露的服务器并列出有风险的账户，请在变更窗口之前运行，而不是事后再补救。

利用情况：蜜罐已证实，其他地方可能普遍存在

目前已证实的情况范围很窄：Previdian观测到来自单一IP地址89.116.89[.]18（地理位置定位在日本）的八次利用尝试，并证实攻击者在一台运行Alpine Linux和OpenSSH的蜜罐上获得了root权限。Previdian创始人兼首席执行官Ryan Dewhurst在向The Hacker News发表的声明中说：“观测到的源IP 89.116.89[.]18使用超长密码绕过认证，并通过非交互式SSH会话执行了id、uname和hostname等侦察命令。”

一次蜜罐命中并不能证明企业已被入侵，但从攻击经济性来看，应当假设存在大规模撒网式尝试。Knott指出，暴露在互联网上的SSH服务器全天候都在遭受密码猜测和暴力破解，而利用SSHole只需在现有的暴力破解字典中加入一个超长密码，watchTowr会非常惊讶，如果暴力破解者几天之内不会尝试这一手法。与此同时，Safe Security提醒人们关注登录之后的风险：“未授权的SSH访问固然是直接影响，但攻击者还可能获取部署凭据、应用机密以及关联基础设施，从而实现横向移动或服务中断。”

检测：排查不可能发生的登录

SSHole会留下一个非常明显的痕迹：一个没有密码的账户成功通过了密码认证。据CSO Online介绍，/var/log/messages中针对root、alpine用户或任何仅使用密钥的账户出现的“Accepted password”记录，是入侵的强烈信号，因为这种事件在健康的系统上本不可能发生。据The Hacker News报道，Alpine官方公告建议防御者在/var/log/messages中搜索sshd记录，查找针对没有密码的账户（alpine账户、root或任何仅使用密钥的用户）的已接受密码认证记录，并检查暴露机器上的doas使用情况，以及近期新建的用户、文件和授权密钥。公告的核心结论是：如果无法排除某次登录，就应将该机器视为已被入侵。

未授权的SSH访问固然是直接影响，但攻击者还可能获取部署凭据、应用机密以及关联基础设施，从而实现横向移动或服务中断。——Safe Security，经The Hacker News引述

排查时需注意一点：由于musl在哈希前会截断超过256字节的密码，恶意尝试在日志中未必显得异常，真正异常的是认证结果。请针对“不可能的成功登录”设置告警，而不是针对密码长度。

缓解措施，以及容器化环境中那头“大象”

修复方法本身很简单：安装OpenSSH 10.6p2或发行版提供的已修补openssh软件包（Alpine已发布紧急更新），然后重启sshd。如果本周无法打补丁，Alpine推荐的临时方案是完全禁用密码认证，改用基于密钥的登录：

# /etc/ssh/sshd_config — the workaround Alpine recommends if you can't patch
PasswordAuthentication no
# then set up key-based auth and restart sshd

真正费力的是盘点工作。只给服务器打补丁就以为万事大吉，会漏掉真正的影响范围，因为Alpine的实际覆盖面在于容器基础镜像。任何基于受影响Alpine版本构建、并运行sshd的镜像，无论是出于调试、旧版部署工具，还是某些早已没人记得的原因，都可能是一扇敞开的后门。大多数组织并没有一份可靠清单，记录哪些正在运行的容器包含SSH守护进程。这与我们此前报道的一个CVSS 10级的LXD和MicroCloud漏洞导致可信客户端被冒充属于同类问题：容器基础设施悄无声息地继承了无人重新审视的信任假设。

因此，长期的修复是流水线问题，而不只是补丁问题。扫描你的镜像仓库和运行中的Pod，查找sshd二进制文件，用已修补的基础镜像重建所有基于受影响Alpine云镜像版本范围的镜像，并直面那个令人尴尬的问题：容器为什么需要交互式SSH服务器？基于Alpine的生态系统在压力下已多次暴露脆弱性：GitLab的一个正则表达式远程代码执行漏洞在一次针对Alpine基础设施的攻击之后被列入CISA的KEV目录。而一个潜伏十年、只需一个超长密码即可触发的认证绕过漏洞，正是暴力破解僵尸网络会吸收进字典、且永远不会删除的那类漏洞。请尽快打补丁，在日志中排查不应存在的登录，并将任何无法排除登录行为的主机视为已被入侵。最后这一点正是Alpine自己的建议，也是正确的警惕态度。