OpenSSH是遠(yuǎn)程管理Linux和BSD系統(tǒng)的最常用工具，近期修復(fù)了兩個(gè)高危漏洞。其中一個(gè)漏洞允許攻擊者在特定配置下對OpenSSH客戶端發(fā)起中間人攻擊，冒充服務(wù)器以攔截敏感通信；另一個(gè)漏洞則可能導(dǎo)致CPU資源耗盡。

漏洞詳情及潛在危害

研究人員在報(bào)告中指出：“SSH會話是攻擊者攔截憑證或劫持會話的主要目標(biāo)。一旦被攻破，黑客可以查看或操縱敏感數(shù)據(jù)，橫向跨越多個(gè)關(guān)鍵服務(wù)器，并竊取諸如數(shù)據(jù)庫憑證等重要信息。此類泄露可能導(dǎo)致聲譽(yù)受損、違反合規(guī)要求（如GDPR、HIPAA、PCI-DSS），并通過迫使系統(tǒng)停機(jī)以遏制威脅，從而破壞關(guān)鍵業(yè)務(wù)。”

此次發(fā)現(xiàn)的中間人漏洞編號為CVE-2025-26465，其代碼缺陷可追溯至2014年12月，距今已有10年之久。該漏洞影響了從6.8p1到9.9p1的所有OpenSSH版本。第二個(gè)漏洞編號為CVE-2025-26466，影響了9.5p1到9.9p1版本。用戶應(yīng)盡快升級至新發(fā)布的OpenSSH 9.9p2版本。

DNS密鑰驗(yàn)證機(jī)制的失效

OpenSSH是SSH（安全外殼協(xié)議）最流行的實(shí)現(xiàn)，由維護(hù)OpenBSD操作系統(tǒng)的OpenBSD項(xiàng)目開發(fā)。OpenBSD以其代碼質(zhì)量和安全性著稱，OpenSSH也不例外。

SSH協(xié)議的工作方式是在交換憑證之前先建立加密連接。客戶端通過查看服務(wù)器的公鑰來驗(yàn)證其身份，類似于TLS協(xié)議。如果密鑰已被信任，握手將繼續(xù)；如果密鑰指紋與客戶端known_hosts文件中存儲的不一致，客戶端會發(fā)出中間人攻擊的警告。

known_hosts文件中的服務(wù)器身份是如何填充的？通常，當(dāng)客戶端首次連接服務(wù)器時(shí)，系統(tǒng)會提示用戶是否接受并信任服務(wù)器提供的密鑰，從而在本地創(chuàng)建記錄。然而，并非所有SSH用戶都是人類，SSH還通過自動化腳本進(jìn)行大量機(jī)器與機(jī)器之間的交互。

為了支持這些自動化腳本信任新配置的服務(wù)器，OpenSSH提供了一個(gè)名為VerifyHostKeyDNS的功能，允許客戶端通過檢查服務(wù)器密鑰是否與其主機(jī)名的SSHFP DNS記錄匹配來自動信任該密鑰。

漏洞成因與利用場景

VerifyHostKeyDNS功能在大多數(shù)部署中默認(rèn)關(guān)閉，但用戶可以在配置中啟用它。2013年9月至2023年3月期間，F(xiàn)reeBSD附帶的OpenSSH包默認(rèn)啟用了該選項(xiàng)。

Qualys研究人員發(fā)現(xiàn)，當(dāng)VerifyHostKeyDNS啟用并設(shè)置為“ask”或“yes”時(shí)，檢查服務(wù)器密鑰的函數(shù)存在邏輯錯(cuò)誤：除-1（SSH_ERR_INTERNAL_ERROR）之外的任何錯(cuò)誤值都不會被視為錯(cuò)誤，反而被認(rèn)為是成功的。通過嘗試不同的錯(cuò)誤代碼，他們發(fā)現(xiàn)只有-2（SSH_ERR_ALLOC_FAIL，內(nèi)存不足錯(cuò)誤）可以被利用。

配合漏洞實(shí)現(xiàn)攻擊

在真實(shí)場景中，如何觸發(fā)客戶端的內(nèi)存錯(cuò)誤？一種方法是在偽造的服務(wù)器上放置一個(gè)超長的密鑰，但由于握手期間交換的數(shù)據(jù)包最大約為256KB，這不足以耗盡客戶端內(nèi)存。因此，研究人員需要另一個(gè)漏洞，在身份驗(yàn)證之前觸發(fā)，并盡可能消耗客戶端進(jìn)程的內(nèi)存，以便在提供偽造服務(wù)器密鑰時(shí)觸發(fā)內(nèi)存不足錯(cuò)誤。

最終，研究人員發(fā)現(xiàn)了第二個(gè)漏洞CVE-2025-26466，該漏洞在初始密鑰交換期間會導(dǎo)致內(nèi)存的無限分配，直到交換結(jié)束才釋放。雖然該漏洞可能導(dǎo)致客戶端和服務(wù)器的拒絕服務(wù)，但在客戶端上，它還可用于為利用第一個(gè)漏洞創(chuàng)造條件，從而實(shí)現(xiàn)中間人攻擊。

研究人員在概念驗(yàn)證場景中解釋道：“如果偽造的服務(wù)器實(shí)施上述內(nèi)存耗盡攻擊（通過分配1024位RSA密鑰、約140KB的證書擴(kuò)展以及約234MB的PONG數(shù)據(jù)包），則客戶端調(diào)用sshkey_from_private()時(shí)返回SSH_ERR_ALLOC_FAIL，從而完全繞過對真實(shí)服務(wù)器主機(jī)密鑰的檢查，使得偽造的服務(wù)器能夠成功冒充真實(shí)服務(wù)器。”