OpenSSHは、Portable OpenSSH 10.6p2をリリースしました。Pluggable Authentication Modules（PAM）を使わず、musl libcを採用する一部のLinuxシステムに影響する、重大な認証バイパスを阻止するものです。
2026年11月5日に公開されたこの脆弱性を悪用すると、パスワード認証を拒否するはずのアカウントに、257〜1,024バイトの任意のパスワードを送信するだけでアクセスできてしまいます。
この問題は「sshole」と名付けられました。Wakefieldの研究者Özgün Kültekin氏が発見したもので、さまざまなOpenSSHビルドで認証の挙動を検証している最中に見つかりました。ただし、メンテナーは根本原因がsshdの外側にあるとみており、今回のリリースをセキュリティ上の回避策と位置付けています。
不具合が発生するのは、sshdのネイティブなパスワード検証の経路です。デーモンは送信されたパスワードをcrypt()でハッシュ化し、その結果を保存済みのパスワードフィールドと比較します。
/etc/shadowにアスタリスク1文字だけが入っているアカウントは、正規のパスワードハッシュと一致するはずがありません。ところがmuslは、パスワードのハッシュ化に失敗すると、これと同じアスタリスクを返します。
悪意あるpam_unix.so認証バックドアとは異なり、今回のバイパスでは差し替え用のバイナリも事前の侵害も必要ありません。エラー処理の不整合により、ハッシュ化の失敗が、一見成功したかのような認証情報の比較結果に変わってしまうのです。
muslのSHA-256およびSHA-512のパスワードハッシュ実装は、256バイトを超える入力を拒否します。そのため、sshdが過大なサイズのパスワードを受け取ると、crypt()は"*"を返します。
対象アカウントの保存フィールドも"*"であれば、続く文字列比較で両者が等しいと判定されます。さらに、CVE-2016-6210のユーザー名列挙を可能にするタイミング漏えいへの対策として導入されたソルト選択の仕組みが、対象アカウントに使えるパラメータがない場合、別のアカウントのハッシュ化パラメータを供給します。
この相互作用により、パスワード検証がSSHプロトコルの認証境界に結び付きます。SSHの暗号を破ったり、認証情報を復元したりするものではありません。
悪用にはいくつかの条件が同時に必要です。sshdがmuslを使用し、PAMなしで認証を行い、パスワードログインを許可し、パスワードフィールドがちょうど"*"であるアカウントが存在することです。
加えて、別のローカルアカウントが、使用可能なSHA-256またはSHA-512のパスワードハッシュを持っている必要があります。Alpine Linuxは、標準のOpenSSHサーバーパッケージがデフォルトでPAMを使用しないため、特に注意が必要です。
標的になり得るのは、サービスアカウント、デプロイ用ユーザー、クラウドIDなどです。musl系ディストリビューションやAlpineコンテナを動かしているだけで、影響を受けるとは限りません。影響を受けるsshd設定に外部からアクセスできることが条件です。
影響の大きさは、乗っ取られたアカウントの権限と、適用されているSSHアクセス制御によって決まります。AlpineのAWSおよびAzure公式イメージは、デフォルトのalpineアカウントがパスワードなしでdoasを使えるため、アカウントを乗っ取られるとroot権限での実行を許す点で要注意です。
rootアカウントが常にアクセス可能とは限らず、サーバーのポリシーがログインを許可している必要があります。クライアント側のコマンド処理を狙うProxyCommandのシェルインジェクションとは異なり、ssholeはサーバー側のパスワード検証を攻撃します。glibc、PAM認証、Dropbearを使うシステムは、影響を受ける組み合わせに当てはまりません。
管理者は、OpenSSH 10.6p2か、修正がバックポートされたディストリビューションのパッケージを導入し、sshdを再起動してください。このパッチは、比較を受け付ける前に、保存されたハッシュが少なくとも4文字を含むことを求めます。また、静的バッファのエイリアシングを避けるため、パスワードフィールドをコピーします。
パッチ適用を待たざるを得ない場合は、PasswordAuthentication noを設定してパスワード認証を無効にし、サービスを再起動してください。調査担当者は、使用可能なパスワードを持たない設定のアカウントでパスワード認証が成功したイベントを確認し、想定外のアクセスは侵害の可能性があるものとして調べる必要があります。
16,000以上のSOCチームが、脅威調査の効率化と手作業の削減のためにANY.RUNを活用しています。チームで試してみる
翻訳元: https://cyberpress.org/critical-openssh-authentication/
