Alpine Linux の OpenSSH に重大な脆弱性、長いパスワードでログイン可能

OpenSSH の重大な脆弱性により、攻撃者は過度に長いパスワードを送信することで、特定の Alpine Linux 構成における認証をバイパスできるようになります。OpenSSH プロジェクトは 2026 年 11 月 5 日にバージョン 10.6p2 をリリースしてこの問題に対処し、Alpine Linux はサポートされているすべてのリリースに対して修正をバックポートしました。

何が起きたか

ネットワークアクセスを持つ攻撃者は、SSH キーのみを使用するユーザーやクラウドイメージ内のデフォルトの alpine ユーザーなど、パスワードが設定されていないユーザーアカウントにログインできます。成功するためには、攻撃者はアカウント名を知っている必要があり、257 バイトから 1,024 バイトの長さのパスワードを入力する必要があります。この欠陥は特に、Pluggable Authentication Module (PAM) インターフェースなしでビルドされた、Alpine Linux 上の標準的な openssh-server パッケージを実行しているシステムに影響します。

この脆弱性は、OpenSSH のパスワードチェックロジックと、Alpine が使用する C ライブラリである musl との相互作用によって生じます。パスワード認証が有効になっており、少なくとも 1 つの他のローカルアカウントにパスワードハッシュが存在する場合、サーバーは空のパスワードフィールドを持つ任意のアカウントに対して長いパスワードを誤って受け入れます。現時点ではアクティブなエクスプロイトは報告されていませんが、OpenSSH チームはこの欠陥を「クリティカル」と評価し、即時の緩和策を強く求めました。

OpenSSH プロジェクトの Damien Miller 氏は緊急性を強調し、管理者は「これらのシステムでは IMMEDIATELY（直ちに）PasswordAuthentication=no を設定するか SSH を無効化してください」と述べました。修正は迅速にリリースされ、Miller 氏は、AI エージェントが数時間でこうしたバグを再発見できるようになったため、長い公開禁止期間（エンバーゴ）はますます危険になっていると指摘しました。

仕組み

根本原因は、PAM が使用されていない場合に sshd がパスワード検証をどのように処理するかに関わっています。通常、sshd は crypt() 関数を使用して提供されたパスワードをハッシュ化し、/etc/shadow に保存されているハッシュと比較します。パスワードがないアカウントには、このフィールドに * 文字が含まれています。* はソルトを含むには短すぎるため、sshd はパスワードハッシュを持つ別のアカウントからソルトを借用します。

攻撃者が 256 バイトを超えるパスワードを送信すると、musl の crypt() 関数はその処理を拒否し、エラーを示すために * を返します。ターゲットアカウントの保存済みフィールドも * であるため、比較が成功し、サーバーはアクセスを許可します。この動作は、crypt() の失敗をチェックしないプログラムでのクラッシュを防ぐために 2012 年に musl に行われた変更と、ユーザー名の列挙を防ぐために 2016 年に OpenSSH に行われた変更の結果として生じています。

新しいバージョン 10.6p2 では、保存されたパスワードフィールドが 4 文字未満の場合、一致を拒否するワークアラウンドが導入されました。これにより攻撃は停止しますが、OpenSSH チームは、根本的な問題は SSH 自体ではなく、C ライブラリの長い入力に対する処理にあると指摘しています。

主要な詳細

• 影響を受けるシステム: PAM なしの openssh-server を実行している Alpine Linux、または UsePAM no を指定した openssh-server-pam。
• 前提条件: PasswordAuthentication が yes であり、少なくとも 1 つのアカウントに $5$ または $6$ ハッシュがあり、ターゲットアカウントのパスワードフィールドが * であること。
• 攻撃ベクトル: 257 バイトから 1,024 バイトの長さのパスワードを用いた単一の接続試行が、毎回成功します。
• 高リスクターゲット: tiny-cloud イメージ（バージョン 3.18.11 から 3.24.3）内の alpine ユーザーは、システム上にいずれかのパスワードハッシュが存在すると脆弱になり、doas を介してルートアクセスを取得される可能性があります。
• 影響を受けないシステム: glibc を使用する Linux ディストリビューション、認証に PAM を使用しているシステム、および Dropbear を使用している OpenWrt デバイス。
• 修正の入手可能性: OpenSSH 10.6p2 は現在利用可能です。Alpine はバージョン 3.16 から 3.24 までのパッケージを更新しました。

なぜ重要なのか

Alpine Linux 上でインフラストラクチャを構築するエンジニアにとって、この脆弱性はキーのみの認証セットアップのセキュリティを損なうものです。多くの開発者はコンテナやクラウドインスタンスでのフットプリントの小ささを理由に Alpine を採用しており、パスワードログインの無効化や SSH キーの使用だけで十分な保護を提供していると仮定しがちです。しかし、多くの構成で PasswordAuthentication がデフォルトで有効になっているため、明示的にハードニングされない限り、これらのシステムはさらされたままとなります。

この事案はまた、オープンソースメンテナーがパッチを迅速にリリースすることへの圧力が高まっていることを浮き彫りにしています。従来の公開禁止期間をスキップするという決定は、自動化ツールが脆弱性を急速にリバースエンジニアリングできるようになった変化する脅威環境を反映しています。チームは現在、迅速なパッチ適用サイクルを優先し、重大な欠陥の技術的詳細が発見後ほぼ即座に公知の情報になる可能性があることを想定する必要があります。

対応方法

• apk upgrade -U -a を使用して Alpine パッケージを直ちに更新し、rc-service sshd restart で SSH サービスを再起動してください。
• すぐに更新できない場合は、SSH 構成で PasswordAuthentication no を設定してパスワード認証を無効にしてください。
• sshd -T | grep -i passwordauthentication を実行して構成変更を検証し、no が返されることを確認してください。
• /var/log/messages を確認し、root や alpine など、パスワードアクセスを持つべきでないユーザーに対する Accepted password for というエントリを探してください。
• 潜在的にさらされているマシンで doas の使用状況と最近作成されたユーザーを確認し、不審な活動が見つかった場合は侵害されたものとして扱ってください。
• OpenSSH を実行している Buildroot や Yocto などのその他の musl ベースのシステムを監査してください。ただし、Dropbear を使用している OpenWrt は一般的に安全です。