musl環境のOpenSSHでのパスワード認証の回避
- カテゴリ
- 脆弱性の公表
Alpine Linuxの2026年11月5日の勧告では、PAMを使わずに動くsshdで、条件がそろうと、パスワード欄が「*」のアカウントに257〜1,024バイト〔注1〕の任意のパスワードでログインできる［2］。OpenSSHは11月5日、sshd側でこの問題を避ける10.6p2を公開した［1］。
脆弱性の内容
OpenSSHは10.6p2のリリースノートで、この版がmusl libcを使いPAMを無効にしたLinuxシステムに影響する重大なセキュリティ上の回避策を含むと説明した［1］。不具合の根本原因はsshdの外にあると考えているが、sshdを通じて悪用でき、sshdで避けられるとした［1］。報告者はWakefieldのÖzgün Kültekinである［1］。
Alpine Linuxの勧告によると、PAMなしでビルドしたsshdは、入力されたパスワードをcrypt()でハッシュにして、保存されたパスワード欄と比べる［2］。保存された欄がソルトを含むには短すぎるアカウントでは、別のアカウントのソルトを借りる［2］。muslのcrypt()は、鍵が256バイトを超えるとエラーの印として文字列「*」を返す［2］。この「*」がパスワードの無いアカウントの保存された欄と一致し、ログインが成功する［2］。
Alpine Linuxは勧告で、攻撃者に要るのはパスワード欄が「*」のアカウントの名前と、$5$か$6$のハッシュを持つ別のアカウントが1つ以上あることだと説明した［2］。パスワードを持つ利用者が1人いれば、パスワードの無いすべてのアカウントに届き、1回の接続で毎回成功する［2］。The Hacker Newsは、範囲の上限の1,024バイトはsshd自身のパスワード1件あたりの上限だと報じた［6］。
muslのメーリングリストに11月5日に出た告知では、これはmuslの不具合ではなく呼び出し側の誤った使い方だというのが投稿者の立場である［3］。一方で、これが起きた仕組みは以前から変えたかったもので、次のリリース周期で変わる可能性が非常に高いと述べた［3］。
発見者が公開した解説サイトsshhole.comによると、発見者はglibcとmusl、PAMのあり・なしなどの組み合わせでsshdをビルドし、約17,600回の変則的なログインを試した［5］。試行には多数のエージェントを使い、PAMなしのmuslのビルドだけが許すべきでないログインを許した［5］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2012年 | musl | crypt()が失敗したときにNULLでなく「*」を返すようにした（コミットb3c4cc12） | ［5］ |
| 2012年 | musl | sha512 cryptを加え、256バイトを超えるパスワードを拒むようにした（コミット88bf5a8a） | ［5］ |
| 2016年 | OpenSSH | CVE-2016-6210の修正で、本物のハッシュの無い利用者にも別のアカウントのソルトでハッシュを計算するようにした | ［5］ |
| 2026年 | - | セキュリティの見直しでpick_salt()を直した（不具合はその4行下にあった） | ［5］ |
| 2026年 | musl | OpenSSHとmuslの利用者向けの告知を出した | ［3］ |
| 2026年 | CVE Program | CVE-2026-123158を公開した | ［4］ |
対象の製品と版
Alpine Linuxの勧告では、影響を受けるのは4つの条件をすべて満たすときである［2］。
- PAMなしでビルドしたopenssh-serverパッケージか、UsePAM noのopenssh-server-pamを使っている［2］
- PasswordAuthenticationがyes（OpenSSHの既定）である［2］
- パスワード欄が「*」のアカウントがある［2］
- ローカルのアカウントの1つ以上が$5$か$6$のハッシュを持つ［2］
パスワード欄が「*」のアカウントとして、勧告は3.16ごろから基本イメージで「root:*」になっているroot、パスワードなしでadduserしたかusermod -p '*'で作った鍵だけの利用者、musl-nscd経由のディレクトリサービスの利用者、tiny-cloudイメージのalpine利用者を挙げた［2］。rootは既定のPermitRootLogin prohibit-passwordで守られるが、doasなどでrootになれる別のアカウントがあれば助けにならない［2］。影響を受けるリリースは、確かめた3.21〜3.24とedge、通常の更新が終わった3.16〜3.20である［2］。
3.18.11〜3.24.3の公式tiny-cloudイメージ（qcow2・VHD・AMI）には、パスワード欄が「*」で、パスワードなしのdoasを持つalpine利用者がある［2］。最初の起動では安全だが、管理者がコンソールのパスワードを設定するなどして$6$のハッシュが1つでもできると悪用でき、攻撃者はalpineとしてシェルを得てdoasでrootになれる［2］。
勧告は、sshdをコンテナで動かさない利用者、PasswordAuthentication noのシステム、UsePAM yesのopenssh-server-pam、パスワード欄が「!」のロックされたアカウント、cloud-initで構成したクラウドイメージは影響を受けないとした［2］。muslの告知では、DropbearとOpenSSH以外のパスワードでのログインを使うソフトウェアも影響を受けない［3］。The Hacker Newsは、OpenSSHのDamien MillerがLinux以外のシステム、glibcのLinux、PAMでパスワードを確かめるシステムは影響を受けないと述べたと報じた［6］。同じ記事は、OpenWrtは既定でDropbearを使い、管理者がOpenSSHのサーバーを入れた場合にだけ問題になりうるとも伝えた［6］。
| ブランチ | 修正版のopenssh | 資料 |
|---|---|---|
| edge | 10.6_p2-r0 | ［2］ |
| 3.24 | 10.3_p1-r2 | ［2］ |
| 3.23 | 10.2_p1-r1 | ［2］ |
| 3.22 | 10.0_p1-r11 | ［2］ |
| 3.21 | 9.9_p2-r1 | ［2］ |
| 3.20 | 9.7_p1-r6 | ［2］ |
| 3.19 | 9.6_p1-r3 | ［2］ |
| 3.18 | 9.3_p2-r4 | ［2］ |
| 3.17 | 9.1_p1-r7 | ［2］ |
| 3.16 | 9.0_p1-r6 | ［2］ |
Alpine Linuxは、3.21.10・3.22.8・3.23.8・3.24.4が修正済みのパッケージを含み、それ以降のtiny-cloudイメージも修正済みだと説明した［2］。3.21は11月1日にサポートを終えたが、3.16までの各リリースに修正済みのパッケージを出した［2］。
悪用の状況
The Hacker Newsは、この欠陥を使った攻撃は報告されていないと報じた［6］。CVE記録にCISAが加えたSSVCの評価は、Exploitationがpoc、Automatableがno、Technical Impactがtotalである［4］。
Alpine Linuxの勧告は、攻撃を受けたかを確かめる方法として、パスワードを持たないアカウント（alpine、root、鍵だけの利用者）についてsshdがパスワードでのログインを受け付けた記録を探すよう求めた［2］。公開されたマシンではdoasの使用、最近作られた利用者・ファイル・authorized keysも確かめる対象で、ログインを否定できなければ侵害されたものとして扱うとした［2］。
修正と回避策
Alpine Linuxの勧告が示した対処の手順は4つある［2］。
- apk upgrade -U -aでパッケージを更新する［2］
- パッケージの更新は動いているsshdを再起動しないので、更新の後にsshdを再起動する（rc-service sshd restart）［2］
- すぐに更新できなければ、鍵でのログインが動くことを確かめてから、PasswordAuthentication noにしてsshdを再起動する［2、3］
- sshd -Tでpasswordauthentication noと表示されることを確かめる（sshd_config.dのドロップインを既定の設定が読むのは3.19から）［2］
The Hacker Newsは、Millerが影響を受けるシステムの運用者に、PasswordAuthenticationをnoにするかSSHを直ちに無効にするよう求めたと報じた［6］。10.6p2のコードの変更は、保存された欄が4文字より短いときにsshdに一致を拒ませるものだと、同じ記事は伝えた［6］。Alpine Linuxの安定ブランチのパッケージは、同じ問題への修正を含む［2］。
The Hacker Newsによると、Millerのチームは今週初めにこの欠陥を知り、できるだけ早く修正を出した［6］。Millerは公開の告知で、長いエンバーゴは危険で主に攻撃者を利するとチームが考えるようになったと述べ、その理由に、AIエージェントが同じ不具合をときに数時間のうちに再び見つけるのを見てきたことを挙げたと報じた［6］。
未公表の事項
- 影響を受けるサーバーの数
- muslの仕組みの変更の内容と時期（muslの告知は次のリリース周期で変わる可能性が非常に高いと説明した［3］）
- OpenSSHとAlpine Linuxによる悪用の有無の説明
- OpenWrt・Buildroot・Yoctoの配布元の対応
注
出典
当事者
- ［1］OpenSSH Project『Portable OpenSSH 10.6p2 release notes』（2026年11月5日公開）
- ［2］Alpine Linux Development Team『Security advisory: openssh-server password authentication bypass』（2026年11月5日公開）
- ［3］musl libc project『Advisory for OpenSSH+musl users』（2026年11月5日公開）
公的機関
- ［4］CVE Program『CVE-2026-123158』（2026年11月5日公開）
調査・観測
- ［5］Wakefield『*sshole · sshhole.com』（公開日不明、2026年11月6日閲覧）
報道機関
- ［6］The Hacker News『OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux』（2026年11月5日公開）
更新記録
- 2026年11月6日：公開した。