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，從而完全繞過對真實服務器主機密鑰的檢查，使得偽造的服務器能夠成功冒充真實服務器。”