257 位元組的假密碼：掛帳十年的 SSH 漏洞，記在 musl 的體積帳上

密碼越長越安全，這條常識在一臺以 Alpine Linux 為底的伺服器上剛好相反。11 月 5 日，OpenSSH 專案發布緊急更新 10.6p2，修補一個認證繞過漏洞：攻擊者不需要真實密碼，只要能連上目標的 SSH 埠，知道一個未設密碼的帳戶名稱，再送出一段 257 至 1,024 位元組的任意字串，就能登入該帳戶。字串內容是否正確無關緊要，長度才是這把鎖的尺寸。

時間軸比攻擊面更值得攤開。OpenSSH 專案表示，這個問題可能自 2016 年就已存在。將近十年間，一段亂碼就能通過的認證，靜靜躺在每一個符合觸發條件的系統裡，直到本週才被寫進修補程式。目前尚無利用此漏洞的攻擊通報，CVE 編號也還沒有分配。

兩顆星號的重疊：認證為何放行

成因藏在 sshd 與 musl 函式庫的互動裡。musl 是一套輕量級 C 標準函式庫，它的 crypt() 函式有一條邊界規則：密碼超過 256 位元組，直接回傳一個星號。而未設密碼的帳戶，在系統密碼檔裡的儲存值同樣是星號。當無密碼帳戶的儲存欄位過短、給不出鹽值時，sshd 會借用系統內其他帳戶的鹽值繼續運算。於是一段 257 位元組以上的輸入，經 musl 的 crypt() 處理後變成星號，與無密碼帳戶的星號比對相符，登入就此放行。

認證流程的每一步都照規則執行，問題出在兩套實作對同一個符號的語義不同。在同一層介面背後換掉一個元件、行為差異遲遲無人校驗，這類帳先前在中國版 Apple 智慧的雲端架構置換也出現過樣本，只是這次換上的元件是 libc，代價由認證邏輯支付。

並非所有 SSH 伺服器都暴露在這條路徑上。安全研究人員列出的成立條件有四個：伺服器執行未啟用 PAM（插入式驗證模組）的 openssh-server、開啟密碼登入、存在密碼欄位為星號的無密碼帳戶，而且系統內至少還有一個以 5 號（SHA-256）或 6 號（SHA-512）前綴雜湊儲存密碼的帳戶。Alpine Linux 的預設建置恰好符合前兩項，這正是它被點名的原因。

省下的體積，未付的驗證費

Alpine 押注 musl，出發點是體積。以 musl 為底的 Alpine 基礎容器鏡像，壓縮後僅個位數 MB；以 glibc 為底的 Debian 或 Ubuntu 鏡像，動輒數十 MB 起跳。在每天重建大量容器的 CI/CD 管線裡，這個差距乘上拉取與建置次數，就是可觀的頻寬、儲存與建置時間支出。輕量是 Alpine 在容器生態站上基底位置的核心理由，也是 musl 從嵌入式邊緣走進雲端視野的通道。

這筆帳有一欄始終沒列：安全驗證的覆蓋率。多數主流發行版採用 glibc，滲透測試、模糊測試與人工審計的資源也集中在 glibc 環境，OpenSSH 與 musl 的組合行為長期處在主流驗證的視野邊緣。回看 2014 年 OpenSSL 的 Heartbleed 事件，基礎安全元件的審計投入此後明顯增加，但資源多半流向被直接攻擊的元件本身，元件之間的介面縫隙仍是分配的盲區。軟體跨到非原生環境執行，最深的坑常在最底層，先前把 iPadOS 移植進小米 17 Ultra 的專案卡在 WiFi 驅動，這次輪到 libc 的 crypt()。

十年沒人發現，不代表十年沒人走過。SSH 埠是網路上被掃描最頻繁的服務之一，漏洞未見攻擊通報，可能因為確實無人利用，也可能因為攻擊留下的紀錄與正常登入同型。官方的補救指引把判斷標準寫得很直接：日誌中若出現針對 root、alpine 或僅金鑰帳戶的「Accepted password」紀錄，且無法排除異常，該主機應視為已遭入侵。

一條指令的修補，一整套的重建

修補指令本身很短。執行 apk upgrade -U -a 更新套件、重啟 sshd 即完成；Alpine 已為 3.16 至 3.24 多個版本發布修補，3.21.10、3.22.8、3.23.8 與 3.24.4 等點版本均已包含。暫時無法升級的環境，官方建議把 PasswordAuthentication 設為 no，改用金鑰登入，把這條密碼路徑整個關掉。

真正的成本在指令之外。以 Alpine 為底的容器鏡像，每一個都要重新建置、重新推送、重新部署，企業環境裡乘上數百個服務，修補就從一條指令變成一項專案。日誌排查同樣喫人力，接著要檢查 doas 的使用紀錄、新建使用者、檔案變動與授權金鑰。這套程序乘上主機數量，才是漏洞的完整帳單。

嵌入式端的帳拖得更長。OpenWrt 預設使用 Dropbear，不在影響範圍，只有管理員另行安裝 OpenSSH 伺服器才可能暴露；Buildroot 與 Yocto 這類以 musl 為底的建置系統則被點名需要排查。嵌入式裝置的更新週期以年計，部分裝置出廠後從未收過更新，這批長尾會把修補曲線拉得又長又平。

帳單上的受惠與承壓

承壓端分三層。Alpine 與 musl 系發行版承擔信譽成本，修補發布速度是一次停損，但「預設建置符合觸發條件」這個標籤會留在選型討論裡。容器維運端承擔重建成本，鏡像數量即工作量。嵌入式裝置承擔長尾風險，且這類裝置往往缺少完整日誌，事後排查的難度最高。

受惠端同樣具體。glibc 陣營的主流發行版，此一漏洞不在其範圍內，在基礎鏡像選型上多了一條論述。鏡像掃描與組態稽核工具的需求上升，組態面的兩個高槓桿項目（停用密碼登入、改用金鑰）正是這類工具檢查清單上的常客。金鑰式存取管理與憑證化 SSH 方案，也獲得一次具體的採購理由。至於 OpenSSH 專案本身，更新與排查指引同步交付，回應速度是開源維護體系的信譽資產。

三種情境

情境一，快速收口。雲端容器生態的鏡像重建在數週內完成，主要暴露面集中收斂，剩餘風險落在零星的自建伺服器與未更新的內部環境。CVE 編號若完成分配，掃描器的全面告警會再推一波修補，帳單在兩個月內結清大半。

情境二，長尾潛伏。嵌入式與老舊裝置多年不更新，漏洞轉入慢速利用期。由於成功利用留下的日誌與正常登入同型，攻擊者又能清理紀錄，這一段的損失難以統計，只會以零星事故的形式浮現。對照多個舊漏洞至今仍在野外被利用的慣性，此情境的機率不低。

情境三，生態重新計價。musl 路線獲得更多審計投入，發行版擴編安全團隊，或企業直接贊助程式碼審查；保守的維運端則在基礎鏡像選型時，把主流覆蓋率加進比價欄位。Alpine 的體積優勢從此要扣除一筆風險溢價才可比較，輕量化的收益以 MB 計，這次缺口的成本以年計，兩個欄位終於出現在同一張報表上。