従来のセキュリティ常識では、システムによってロックされたアカウントにログインすることは不可能です。どんなパスワードを入力しても即座に拒否されるはずでした。しかし2026年11月5日、軽量Linuxディストリビューション「Alpine Linux」が公開したセキュリティ勧告は、この常識を根底から覆しました。
攻撃者が256バイトを超える長いパスワードを入力するだけで、ロックされていたはずの管理者アカウントが扉を開いてしまうのです。このプロセスではメモリ破壊も、パスワードハッシュの総当たり攻撃も行われていません。防御機構が入力値とロックフラグを照合した結果、正規の認証とみなして接続を自ら許可してしまったのです。
この不可解な認証バイパスは、独立して設計された3つの防御ロジックの不測の衝突によって生じました。「計算失敗」を示すエラー値と「ログイン禁止」を表すアカウント状態が同一の文字で表現されていたため、境界での判定ロジックが破綻しました。
3つの防御策が重なり、257文字の入力でゲートが開く
Unix系OSのパスワードシャドウファイル /etc/shadow において、アスタリスク * は数十年にわたりアカウントのロック状態を示してきました。パスワードフィールドが単一の * であれば、システムはパスワード認証を無効と判断します。正規のパスワードハッシュは数十文字に及ぶため、単一のアスタリスクと一致することは理論上あり得ません。
一方、OpenSSHの開発者たちは、攻撃者が既存のユーザー名を探索するタイミング攻撃を防ぐための仕組みを導入していました。有効なパスワードを持たないアカウントであっても、認証処理は直ちにエラーを返しません。システム内の別のアカウントからソルトを借用し、同等の計算時間を要するダミーハッシュを計算します。これにより、アカウントの存在有無による応答時間の差を平坦化していました。
さらに、軽量C標準ライブラリであるmuslにも固有の防御線がありました。悪意ある長文入力によるメモリ枯渇を防ぐため、muslの crypt() 関数には上限値が設定されています。入力が256バイトを超えると関数の計算は打ち切られ、エラーを示す戻り値として静的なアスタリスク * へのポインタが返されます。
これら3つの仕組みは、個別に検証すればいずれも堅牢な防御思想に基づいています。しかし、それらが同一システム内で連携した瞬間、攻撃ルートが完成してしまいました。
攻撃に必要な前提条件は以下の4点のみです：
- 対象ホストのSSHポートへ接続できること
- shadowファイル内でパスワードフィールドが
*になっているアカウントが存在すること（Alpine 3.16以降の初期rootなど） - システム内に
$5$や$6$形式の正規ハッシュを持つアカウントが少なくとも1つ存在すること - 257〜1024バイトの超長文パスワードを送信すること
これら4つの条件が揃うと、OpenSSHは長大なパスワードを受け取り、借用したソルトを用いてダミー計算を開始します。基盤となるmuslは文字数制限を検知してエラーマーカー * を返却します。そしてOpenSSHがこの戻り値とshadowファイルのパスワードフィールドを比較すると、双方とも単一のアスタリスク * となり一致と判定され、ロックされたはずのアカウントへのログインが成立してしまいます。
図：PAM無効環境下での認証バイパスを公表したAlpine Linux公式セキュリティ勧告。出典：alpinelinux.org
アスタリスクが持つ2つの意味：アカウント施錠と計算失敗
この脆弱性の核心は、ソフトウェアスタックの異なる階層間で、同一の記号に全く正反対の意味が与えられていた点にあります。上位層はその文字を「強固な鍵」とみなし、下位ライブラリは「降伏の白旗（エラー）」として返却していました。
従来のUnix実装では、暗号化関数に不正な入力が渡されるとヌルポインタを返すのが一般的でした。呼び出し側がNULL判定を行うことで計算の成否を判別できます。しかしヌルポインタの返却はレガシーコードでのヌルポインタ参照クラッシュを招く恐れがありました。そこでmuslは規格に準拠し、エラー時に静的文字 * へのポインタを返す仕様を採用していました。
この設計は、呼び出し側がアスタリスクを無効なハッシュと解釈することを前提としています。通常のアカウント検証であれば、アスタリスクと実際のパスワードハッシュが一致することはないため問題になりません。
しかし、OpenSSHのダミーソルト機構が致命的な隙を生みました。PAMモジュールを使用しない軽量環境では、sshdプロセス自身がパスワード照合を行います。タイミング差によるアカウント判定を防ぐため、ロック中アカウントに対しても暗号化ルーチンを実行してしまったのです。
結果として、OpenSSHは「パスワードの検証が正常に行われた」と誤認し、実際にはライブラリが計算を中断してエラーを返しただけでした。インターフェース仕様の解釈のズレが、ロック用の静的記号を通行手形に変えてしまったのです。
クラウドイメージに潜む罠：一般ユーザー追加で発火するリスク
脆弱性の公表後、実環境における影響範囲の検証が急速に進みました。すべてのAlpine環境が直ちに危険というわけではなく、実際のリスクは構成に大きく左右されます。
独立したマイクロサービスを稼働させるだけの軽量コンテナでは、通常SSHポート自体が開放されていないため攻撃を受けることはありません。また、パスワード認証を無効化（PasswordAuthentication no）しているホストも安全です。PAMモジュールによる認証を採用しているディストリビューションや構成では、検証が独立したモジュールに委ねられるため、この直接比較は発生しません。
重大なリスクを抱えていたのはクラウドテンプレートでした。Alpine公式が提供するtiny-cloudイメージ（バージョン3.18.11から3.24.3）には、初期ユーザーとして alpine が標準で用意されていました。このアカウントのshadowフィールドは * であり、かつパスワードなしのsudo権限が付与されていました。
プロビジョニング直後の新規環境では、このアカウントは安全でした。なぜなら、システム内にソルトを持つ正規ユーザーが他に存在しないため、OpenSSHがダミー計算を起動できなかったからです。運用担当者が「初期状態のままなら安全」と誤解しやすい構造でした。
しかし、管理者が業務用の一般ユーザーを1つでも作成し、パスワードハッシュがshadowに記録された瞬間、休眠していた alpine アカウントが即座に外部からの侵入ルートへ変貌します。攻撃者は257バイト以上のパスワードを入力するだけで、瞬時にroot権限を掌握できる状態に陥っていました。
パッケージ更新後はsshdプロセスの再起動が必須
本件の公表時、固有のCVE番号は割り当てられませんでした。セキュリティ研究者のÖzgün Kültekin氏がこの挙動を発見し、OpenSSHおよびAlpineチームによって迅速に修正が施されました。修正内容はOpenSSH 10.6p2のリリースノートに記載され、Alpine 3.16から3.24、およびedgeブランチへバックポートされています。
影響を受けるシステムは、直ちにリポジトリを同期してパッケージを更新する必要があります。Alpine環境で apk upgrade -U -a を実行することで、修正版のOpenSSHが導入されます。修正後のコードでは、ライブラリから返却される異常な文字列が厳格に検証され、記号の混同が遮断されます。
図：超長文パスワードとダミーソルト照合ロジックの修正を詳述するOpenSSH 10.6p2のリリースノート。出典：openssh.com
重要な注意点として、ディスク上のバイナリを更新しただけではリスクは解消されません。メモリ上で稼働し続けている既存のsshdプロセスは古いロジックのままであり、攻撃を許してしまいます。パッケージの更新完了後は、必ず rc-service sshd restart を実行してサービスプロセスを再起動し、新バイナリを適用する必要があります。
メンテナンスウィンドウの都合ですぐに再起動できない本番環境では、設定変更による緊急対処が推奨されます。/etc/ssh/sshd_config.d/00-no-passwords.conf に PasswordAuthentication no を記述して設定を再読み込みし、sshd -T でパスワード認証が無効化されたことを確認します。過去ログの調査においては、/var/log/messages 内でパスワード未設定アカウントに対するログイン成功ログがないか確認することが侵入検知の指標となります。
ソフトウェアセキュリティの破綻は、システムの境界部分で頻繁に発生します。個々のコンポーネントが防御ベストプラクティスを遵守していても、シンボルの解釈に微細な不一致が存在すれば、堅牢な防御線も内部から崩壊します。記号や戻り値の意味を一意かつ厳格に保つことは、多層防御の積み重ね以上に根本的なエンジニアリングの原則です。
参考リンク：
- Alpine Linux セキュリティ勧告
- OpenSSH 10.6p2 リリースノート
- Lobsters コミュニティ技術ディスカッション
