OpenSSH是远程管理Linux和BSD系统的最常用工具，近期修复了两个高危漏洞。其中一个漏洞允许攻击者在特定配置下对OpenSSH客户端发起中间人攻击，冒充服务器以拦截敏感通信；另一个漏洞则可能导致CPU资源耗尽。
漏洞详情及潜在危害
研究人员在报告中指出：“SSH会话是攻击者拦截凭证或劫持会话的主要目标。一旦被攻破，黑客可以查看或操纵敏感数据，横向跨越多个关键服务器，并窃取诸如数据库凭证等重要信息。此类泄露可能导致声誉受损、违反合规要求（如GDPR、HIPAA、PCI-DSS），并通过迫使系统停机以遏制威胁，从而破坏关键业务。”
此次发现的中间人漏洞编号为CVE-2025-26465，其代码缺陷可追溯至2014年12月，距今已有10年之久。该漏洞影响了从6.8p1到9.9p1的所有OpenSSH版本。第二个漏洞编号为CVE-2025-26466，影响了9.5p1到9.9p1版本。用户应尽快升级至新发布的OpenSSH 9.9p2版本。
DNS密钥验证机制的失效
OpenSSH是SSH（安全外壳协议）最流行的实现，由维护OpenBSD操作系统的OpenBSD项目开发。OpenBSD以其代码质量和安全性著称，OpenSSH也不例外。
SSH协议的工作方式是在交换凭证之前先建立加密连接。客户端通过查看服务器的公钥来验证其身份，类似于TLS协议。如果密钥已被信任，握手将继续；如果密钥指纹与客户端known_hosts文件中存储的不一致，客户端会发出中间人攻击的警告。
known_hosts文件中的服务器身份是如何填充的？通常，当客户端首次连接服务器时，系统会提示用户是否接受并信任服务器提供的密钥，从而在本地创建记录。然而，并非所有SSH用户都是人类，SSH还通过自动化脚本进行大量机器与机器之间的交互。
为了支持这些自动化脚本信任新配置的服务器，OpenSSH提供了一个名为VerifyHostKeyDNS的功能，允许客户端通过检查服务器密钥是否与其主机名的SSHFP DNS记录匹配来自动信任该密钥。
漏洞成因与利用场景
VerifyHostKeyDNS功能在大多数部署中默认关闭，但用户可以在配置中启用它。2013年9月至2023年3月期间，FreeBSD附带的OpenSSH包默认启用了该选项。
Qualys研究人员发现，当VerifyHostKeyDNS启用并设置为“ask”或“yes”时，检查服务器密钥的函数存在逻辑错误：除-1（SSH_ERR_INTERNAL_ERROR）之外的任何错误值都不会被视为错误，反而被认为是成功的。通过尝试不同的错误代码，他们发现只有-2（SSH_ERR_ALLOC_FAIL，内存不足错误）可以被利用。
配合漏洞实现攻击
在真实场景中，如何触发客户端的内存错误？一种方法是在伪造的服务器上放置一个超长的密钥，但由于握手期间交换的数据包最大约为256KB，这不足以耗尽客户端内存。因此，研究人员需要另一个漏洞，在身份验证之前触发，并尽可能消耗客户端进程的内存，以便在提供伪造服务器密钥时触发内存不足错误。
最终，研究人员发现了第二个漏洞CVE-2025-26466，该漏洞在初始密钥交换期间会导致内存的无限分配，直到交换结束才释放。虽然该漏洞可能导致客户端和服务器的拒绝服务，但在客户端上，它还可用于为利用第一个漏洞创造条件，从而实现中间人攻击。
研究人员在概念验证场景中解释道：“如果伪造的服务器实施上述内存耗尽攻击（通过分配1024位RSA密钥、约140KB的证书扩展以及约234MB的PONG数据包），则客户端调用sshkey_from_private()时返回SSH_ERR_ALLOC_FAIL，从而完全绕过对真实服务器主机密钥的检查，使得伪造的服务器能够成功冒充真实服务器。”
漏洞详情及潜在危害
研究人员在报告中指出：“SSH会话是攻击者拦截凭证或劫持会话的主要目标。一旦被攻破，黑客可以查看或操纵敏感数据，横向跨越多个关键服务器，并窃取诸如数据库凭证等重要信息。此类泄露可能导致声誉受损、违反合规要求（如GDPR、HIPAA、PCI-DSS），并通过迫使系统停机以遏制威胁，从而破坏关键业务。”
此次发现的中间人漏洞编号为CVE-2025-26465，其代码缺陷可追溯至2014年12月，距今已有10年之久。该漏洞影响了从6.8p1到9.9p1的所有OpenSSH版本。第二个漏洞编号为CVE-2025-26466，影响了9.5p1到9.9p1版本。用户应尽快升级至新发布的OpenSSH 9.9p2版本。
DNS密钥验证机制的失效
OpenSSH是SSH（安全外壳协议）最流行的实现，由维护OpenBSD操作系统的OpenBSD项目开发。OpenBSD以其代码质量和安全性著称，OpenSSH也不例外。
SSH协议的工作方式是在交换凭证之前先建立加密连接。客户端通过查看服务器的公钥来验证其身份，类似于TLS协议。如果密钥已被信任，握手将继续；如果密钥指纹与客户端known_hosts文件中存储的不一致，客户端会发出中间人攻击的警告。
known_hosts文件中的服务器身份是如何填充的？通常，当客户端首次连接服务器时，系统会提示用户是否接受并信任服务器提供的密钥，从而在本地创建记录。然而，并非所有SSH用户都是人类，SSH还通过自动化脚本进行大量机器与机器之间的交互。
为了支持这些自动化脚本信任新配置的服务器，OpenSSH提供了一个名为VerifyHostKeyDNS的功能，允许客户端通过检查服务器密钥是否与其主机名的SSHFP DNS记录匹配来自动信任该密钥。
漏洞成因与利用场景
VerifyHostKeyDNS功能在大多数部署中默认关闭，但用户可以在配置中启用它。2013年9月至2023年3月期间，FreeBSD附带的OpenSSH包默认启用了该选项。
Qualys研究人员发现，当VerifyHostKeyDNS启用并设置为“ask”或“yes”时，检查服务器密钥的函数存在逻辑错误：除-1（SSH_ERR_INTERNAL_ERROR）之外的任何错误值都不会被视为错误，反而被认为是成功的。通过尝试不同的错误代码，他们发现只有-2（SSH_ERR_ALLOC_FAIL，内存不足错误）可以被利用。
配合漏洞实现攻击
在真实场景中，如何触发客户端的内存错误？一种方法是在伪造的服务器上放置一个超长的密钥，但由于握手期间交换的数据包最大约为256KB，这不足以耗尽客户端内存。因此，研究人员需要另一个漏洞，在身份验证之前触发，并尽可能消耗客户端进程的内存，以便在提供伪造服务器密钥时触发内存不足错误。
最终，研究人员发现了第二个漏洞CVE-2025-26466，该漏洞在初始密钥交换期间会导致内存的无限分配，直到交换结束才释放。虽然该漏洞可能导致客户端和服务器的拒绝服务，但在客户端上，它还可用于为利用第一个漏洞创造条件，从而实现中间人攻击。
研究人员在概念验证场景中解释道：“如果伪造的服务器实施上述内存耗尽攻击（通过分配1024位RSA密钥、约140KB的证书扩展以及约234MB的PONG数据包），则客户端调用sshkey_from_private()时返回SSH_ERR_ALLOC_FAIL，从而完全绕过对真实服务器主机密钥的检查，使得伪造的服务器能够成功冒充真实服务器。”
