Alpine Linux の SSH 脆弱性により、長い文字列でパスワードなしのログインが可能に

Alpine Linux は、OpenSSH サーバー実装における深刻な脆弱性に関する緊急セキュリティアドバイザリーを発行しました。この欠陥により、リモート攻撃者はパスワード認証を完全にバイパスし、認証情報を一切知らずに影響を受けるシステムへのシェルアクセスを取得できます。Alpine バージョン 3.16 から 3.24 を実行している管理者は、直ちに openssh パッケージを更新し、SSH デーモンを再起動してこのリスクを解消する必要があります。

何が起きたのか

この脆弱性は、Pluggable Authentication Modules (PAM) なしでビルドされた sshd デーモンに影響します。これは標準的な Alpine の openssh-server パッケージのデフォルト構成です。SSH ポートに到達できる攻撃者は、システム上に少なくとももう一つのローカルアカウントがあり、そのアカウントが標準的なパスワードハッシュを持っている場合、パスワードが設定されていない任意のユーザーアカウントとしてログインできます。この攻撃には単一の接続試行のみが必要であり、リトライやブルートフォース手法を用いずに確実に成功します。

この問題は、サポートされているバージョン 3.21 から 3.24 および非サポートの古いバージョン 3.16 まで、幅広い Alpine リリースに影響します。特に、明示的に無効化されない限り OpenSSH のデフォルトである PasswordAuthentication が有効になっているシステムを狙います。一般的なシナリオとしては、PermitRootLogin yes で設定された root アカウント、パスワードなしで作成された鍵専用ユーザー、およびローカルのシャドウエントリを持たない SSSD や Winbind などのディレクトリサービス経由で管理されるユーザーが含まれます。

公式の tiny-cloud イメージは、初期起動後に修正されている場合に特に脆弱です。これらのイメージは安全なデフォルト設定で出荷されますが、パスワードハッシュを持つユーザーを追加したりコンソールパスワードを設定したりすると、エクスプロイトに必要な条件が生じます。一度トリガーされると、攻撃者はデフォルトの alpine ユーザーとしてログインし、これらの環境でパスワードなしで使用するように設定されている doas を使用して権限を root に昇格させることができます。

仕組み

根本原因は、PAM サポートなしでコンパイルされた場合の OpenSSH のパスワード検証処理にあります。このモードでは、sshd は C ライブラリ関数 crypt() を使用して提供されたパスワードをハッシュ化し、/etc/shadow に保存されたハッシュと比較します。パスワードがないアカウントの場合、保存フィールドにはアスタリスク 1 つ (*) が含まれます。通常、crypt() は入力を処理するために保存ハッシュからのソルトを必要としますが、* を持つアカウントにはソルトがありません。

そのようなアカウントに遭遇した場合、sshd はシステム上の別の有効な $5$ または $6$ ハッシュを持つアカウントからソルトを借用します。攻撃者が長さ 257 バイトから 1024 バイトのパスワード文字列を送信すると、脆弱性がトリガーされます。Alpine で使用される musl C ライブラリは、256 バイトを超えるキーを処理する際にエラー指標として * を返します。ターゲットアカウントの保存フィールドも * であるため、比較が一致し、認証が成功します。

主要な詳細

• 影響を受けるバージョン: Alpine 3.16 から 3.24（edge および非サポートリリースを含む）。
• 前提条件: PAM なしでビルドされた sshd（または UsePAM no）、PasswordAuthentication yes、そして $5$ または $6$ ハッシュを持つ少なくとも 1 つのアカウント。
• ターゲットアカウント: 鍵専用ユーザーやデフォルトの alpine ユーザーなど、パスワードフィールドに * を持つユーザー。
• 修正済みパッケージ: すべてのブランチで利用可能。3.21 向けには 9.9_p2-r1、edge 向けには 10.6_p2-r0 など。
• 検出方法: /var/log/messages を確認し、パスワードのないアカウントに関連付けられた Accepted password for エントリを探します。
• クラウドリスク: 起動後にいずれかのパスワードハッシュが追加された場合、tiny-cloud イメージは悪用可能になります。

なぜ重要なのか

インフラエンジニアや DevOps チームにとって、この脆弱性は「SSH 鍵専用アカウントはパスワードベースの攻撃に対して安全である」という基本的な前提を覆します。多くの組織はコンテナや軽量 VM 用に Alpine を使用しており、root パスワードログインを無効にするだけで十分だと仮定することがよくあります。しかし、このバグは空のパスワードフィールドとシステム上の他のハッシュ化されたパスワードとの間の相互作用を悪用することで、これらの保護をバイパスします。これは、PAM が使用されない最小限のディストリビューションにおけるデフォルト設定のリスクを浮き彫りにします。

悪用の容易さにより、これは特に危険です。ノイズを生成し fail2ban などでブロック可能なブルートフォース攻撃とは異なり、この手法は 1 つのパケットのみを必要とし、失敗した試行の即時痕跡を残しません。攻撃者がクラウドインスタンスへのアクセスを取得すると、迅速に権限を昇格させ、ネットワーク内で横移動を行うことができます。チームはパッケージを更新したかどうかだけでなく、実行中のデーモンが実際に再起動されたかどうかも確認する必要があります。パッケージマネージャーは必ずしもサービスを自動的に再起動しないためです。

対応策

• apk upgrade -U -a を使用してシステムを直ちに更新し、お使いのブランチ向けの修正版がインストールされていることを確認してください。
• 更新後、rc-service sshd restart を使用して SSH デーモンを明示的に再起動してください。更新だけでは実行中のプロセスは再読み込みされません。
• すぐに更新できない場合は、SSH 設定で PasswordAuthentication no を設定してパスワード認証を無効にし、サービスを再起動してください。
• sshd -T | grep -i passwordauthentication を使用して設定を検証し、変更が有効になっていることを確認してください。
• ログを監査し、パスワードを持つべきでないアカウントに対する予期しない Accepted password エントリがないか確認してください。
• クラウドインスタンスを確認し、脆弱性を誤って有効にしてしまった可能性のある追加のユーザーパスワードハッシュがないか検討してください。