Alpine Linuxは2026年11月5日、特定の条件下でパスワードを知らない攻撃者がSSHログインできる脆弱性を公表し、修正版を提供した。OpenSSHも同日、この問題への対策を含むバージョン10.6p2を公開している。公開鍵認証だけで運用しているつもりのアカウントでも、SSHサーバーのsshdがパスワード認証を受け付ける設定になっていれば、条件次第で不正ログインを許す可能性がある。Alpineの公式勧告は、アカウントの運用方針だけでなく、サーバーの実際の認証設定を確認するよう求めている。
今回の問題を理解するうえで重要なのは、アカウントのパスワードを無効にすることと、SSHサーバーのパスワード認証を停止することの違いだ。前者はアカウントに保存された認証情報を変更するのに対し、後者はPasswordAuthentication noによってsshd自体がパスワード認証を受け付けないようにする。この違いは、別のユーザーにパスワードを設定したことで脆弱性の成立条件がそろうクラウド環境の事例にも、既存サーバーの安全性を確認する方法にも関わっている。
パスワードを拒否する「*」が認証を通してしまう仕組み
PAM（Pluggable Authentication Modules）を利用しないsshdは、入力されたパスワードをcrypt()関数で処理し、その戻り値をアカウントに保存された値と照合する。通常、保存されるのはパスワードそのものではなく、照合用に計算されたハッシュ値だ。ただし、パスワードによるログインを禁止するため、正常なハッシュ値の代わりに*という特殊な文字列を保存するアカウントもある。この*は公開鍵を表す記号ではなく、パスワード認証を拒否するための値だ。
Alpineの原因説明によると、sshdは保存された値が短い場合、別のローカルアカウントのパスワードハッシュから「ソルト」を借りる処理を行う。ソルトとは、パスワードをハッシュ化する際に加える値のことである。ところが、muslという標準Cライブラリのcrypt()関数に256バイトを超える入力を渡すと、エラーを示す*が返される。この戻り値がログイン対象アカウントに保存された*と一致するため、パスワードの照合に成功したと誤判定されてしまう。
つまり、本来は認証を拒否するための値と、計算エラーを示す値が同じ文字列になっていたことが原因だ。Alpineが示した攻撃に使用できる入力の長さは257〜1024バイトであり、文字数ではなくバイト数で指定されている。攻撃者はパスワードを解読したり秘密鍵を盗んだりする必要がなく、crypt()が返したエラー値を利用して認証を通過できる。
発見者のWakefieldによる技術的な解説では、この脆弱性が複数のソフトウェアに加えられた変更の組み合わせによって生じた経緯が説明されている。muslは2012年にエラーの報告方法を変更し、入力の長さ制限を導入した。OpenSSHは2016年、処理時間の違いから情報が漏れることを防ぐため、別のアカウントからソルトを取得する処理を追加している。さらにAlpineは2022年、公開鍵によるログインを可能にするため、rootアカウントの保存値を変更したという。これらの変更が重なった結果、今回の認証回避が成立する条件が生まれた。
Wakefieldは、自身の調査報告で、この問題がOpenSSH 7.3p1の公開された2016年以降に存在していたと説明している。したがって、2022年のAlpineの変更によって初めて生まれた脆弱性ではない。一方、OpenSSHのリリースノートは、根本原因がsshdの外部にあるとしながらも、sshdを通じて悪用できる問題として、バージョン10.6p2に対策を組み込んだ。
公開鍵認証専用のアカウントでも侵入される可能性
この脆弱性が成立するには、攻撃者がSSHサーバーにアクセスできるだけでなく、認証方式やアカウントの状態について複数の条件を満たす必要がある。Alpineの標準openssh-serverはPAMを使用しておらず、PAM対応版でもUsePAM noに設定されていれば同様の条件に該当する。さらに、PasswordAuthentication yesが有効で、ログイン対象アカウントの保存値が厳密に*となっており、別のローカルアカウントに$5$または$6$で始まるパスワードハッシュが存在する必要がある。これらは個別に確認するだけでは不十分で、条件の組み合わせによって影響の有無を判断しなければならない。
以下は、Alpineの公式勧告に示された影響条件と対象外の条件を整理したものだ。Wakefieldの調査とOpenSSHの対策説明も踏まえているが、独自の再現実験による結果ではなく、他のLinuxディストリビューションへの影響を一律に判断するものではない。
| 確認する状態 | この認証回避との関係 | 判断する際の注意点 |
|---|---|---|
| sshdを実行していない | 対象外 | Alpineを使用するコンテナすべてが影響を受けるわけではない |
PasswordAuthentication no |
この認証経路を遮断 | アカウントのパスワードを無効にすることとは異なる |
PAM対応版でUsePAM yes |
公式勧告上は対象外 | PAM対応版の導入だけでなく、実効設定の確認が必要 |
PasswordAuthentication yesで、標準版またはUsePAM noのPAM対応版を使用 |
成立条件の一部 | この設定だけで脆弱とは判断できない |
ログイン可能な対象アカウントの保存値が厳密に* |
成立条件の一部 | !とは異なる。Alpineによれば、!は公開鍵によるログインも拒否する |
別のローカルアカウントに$5$または$6$で始まるハッシュが存在 |
成立条件の一部 | 後からパスワードを追加すると、サーバー全体の条件が変わる |
| 到達可能なSSHサーバーで、上記の脆弱な認証経路とアカウントの条件がそろう | 認証回避が成立する可能性 | 個別の条件だけでなく、組み合わせて判断する必要がある |
ここで注意したいのは、公開鍵認証だけでアカウントを運用する方針と、PasswordAuthentication noによってSSHサーバーのパスワード認証を無効にする設定は別物だという点だ。実際の影響は、muslとPAMの使用状況、sshdの認証設定、対象アカウントの保存値、別のアカウントに存在するパスワードハッシュの組み合わせによって決まる。rootアカウントについては、既定のPermitRootLogin prohibit-passwordがパスワード認証を防ぐが、PermitRootLogin yesへ変更していれば攻撃対象になり得る。また、rootへの直接ログインが禁止されていても、一般ユーザーへの侵入後にdoasを利用して権限を昇格させる経路は別途考慮する必要がある。
もっとも、muslを採用しているシステムがすべて影響を受けるわけではない。Ars Technicaの報道では、OpenWrtの標準SSHサーバーはOpenSSHではなくDropbearであり、BuildrootやYoctoへの影響も確認されていないと指摘している。muslを使用する機器の数を、そのまま脆弱な機器の数と見なすことはできない。さらに、同じサーバー上で別のユーザーにパスワードを追加するだけでも成立条件が変わり得るため、個々のアカウントだけでなく、サーバー全体の認証設定と運用状況を確認する必要がある。
初回起動時には安全なクラウド環境も、運用後に脆弱になる
今回の問題が特に厄介なのは、最初は安全だったクラウド環境が、運用中の設定変更によって脆弱になる可能性があることだ。Alpineが公式に挙げているのは、tiny-cloudを使用するバージョン3.18.11〜3.24.3のqcow2、VHD、AMIイメージである。これらのイメージでは、alpineユーザーのパスワード保存値が*に設定されていた。さらに、このユーザーにはパスワードなしでdoasを使用できる権限が与えられている。
Alpineの説明によると、これらのイメージは初回起動時には安全な状態にある。しかし、管理者がコンソールから別のアカウントにパスワードを設定したり、起動時に設定を渡すuser-dataでhashed_passwdを指定したりすると、状況が変わる。サーバー内に$6$で始まるパスワードハッシュが追加されることで、sshdが別のアカウントからソルトを取得する条件がそろい、既存のalpineユーザーが認証回避の対象になり得るためだ。
例えば、公開鍵を配布してクラウドインスタンスの運用を始めた後、別のログイン手段を確保するためにパスワードを追加したとする。この操作によって、パスワードを追加したアカウントだけでなく、もともと保存値が*だったalpineユーザーの安全性まで変わってしまう。しかも、このユーザーはパスワード不要のdoasを使用できるため、侵入に成功した攻撃者はroot権限へ昇格できる。これはrootアカウントへの直接ログインとは異なり、一般ユーザーへの侵入と、その後の権限昇格という二つの段階を経る攻撃だ。
したがって、クラウド環境の安全性を判断するには、イメージ作成時の設定だけでなく、起動後に追加されたパスワードと現在のsshd設定を確認しなければならない。また、配布元が修正版のイメージを公開しても、すでに稼働しているインスタンスが自動的に修正されるわけではない。既存の環境については、インストール済みパッケージを更新し、稼働中のsshdにも修正を反映させる必要がある。
修正済みかどうかはAlpineのブランチとリビジョン番号で確認
Alpineは2026年11月5日の公式勧告で、各ブランチに対応する修正版のパッケージ番号を公開した。OpenSSHの上流版では10.6p2が修正版となるが、Alpineの安定版には、それぞれの既存バージョンに修正を移植したパッケージが提供されている。そのため、OpenSSHのバージョン番号だけを比較するのではなく、使用しているAlpineのブランチとパッケージのリビジョン番号（-r以降）を組み合わせて確認する必要がある。
| 配布元・ブランチ | 公式が示す修正版 |
|---|---|
| OpenSSH上流 | 10.6p2（2026年11月5日公開） |
| Alpine edge | 10.6_p2-r0 |
| Alpine 3.24 | 10.3_p1-r2 |
| Alpine 3.23 | 10.2_p1-r1 |
| Alpine 3.22 | 10.0_p1-r11 |
| Alpine 3.21 | 9.9_p2-r1 |
| Alpine 3.20 | 9.7_p1-r6 |
| Alpine 3.19 | 9.6_p1-r3 |
| Alpine 3.18 | 9.3_p2-r4 |
| Alpine 3.17 | 9.1_p1-r7 |
| Alpine 3.16 | 9.0_p1-r6 |
Alpine 3.21.10、3.22.8、3.23.8、3.24.4には、今回の修正が含まれている。既存環境に対しては、公式がapk upgrade -U -aによるパッケージ更新を案内している。ただし、パッケージを更新しただけでは、すでに動作しているsshdに修正が反映されるとは限らない。更新後はrc-service sshd restartを実行し、SSHサーバーを再起動する必要がある。
すぐにパッケージを更新できない場合は、PasswordAuthentication noを設定し、sshdを再起動する回避策が示されている。ただし、設定変更によって管理者自身がログインできなくなる事態を避けるため、事前に公開鍵認証で接続できることを確認し、既存の接続を維持したまま新しい接続を試すことが望ましい。設定の構文確認にはsshd -t、実効設定の確認にはsshd -Tを使用できる。なお、Alpine 3.19より前のバージョンでは、追加設定ファイルを標準で読み込む仕組みがないため、設定ファイルを配置しただけで対策が有効になったと判断せず、実際に読み込まれる設定へ反映する必要がある。
さらに、修正を適用するだけでなく、過去に不正ログインが発生していなかったかを調査することも重要だ。Alpineは/var/log/messagesを確認し、パスワード保存値が*のアカウントに対してAccepted password forという認証成功記録が残っていないか調べるよう案内している。公開鍵認証専用のはずだったアカウントでパスワード認証が成功していれば、不正アクセスを疑う必要がある。あわせて、doasの実行履歴、新規ユーザーの作成、ファイルやauthorized_keysの変更も確認すべきだ。
ただし、不審なログが見つからないことは、侵入がなかった証明にはならない。Alpineは、侵害の可能性を否定できない場合、すでに侵害されているものとして扱うよう求めている。今回の脆弱性への対応では、修正版パッケージの導入、稼働中のsshdへの反映、過去の不正アクセスの調査をそれぞれ実施する必要がある。公開鍵認証専用という運用方針だけに頼らず、SSHサーバー側でパスワード認証を適切に制御することが、同様の認証回避を防ぐうえでも重要となる。
