セキュリティ
OpenSSHに存在した10年来の脆弱性が修正されました。今すぐパッチを適用してください
特定のLinuxシステムでは、256バイトを超えるパスワードを入力するだけで、攻撃者がroot権限を奪取できる恐れがあります。この脆弱性を発見したWakefieldの研究者Özgün Kültekin氏は、*ssholeと名付けました。ただし、悪用できるのは非常に限られた条件下のみです。
影響を受けるのは、従来のGNU C Libraryではなくmusl libcを採用した一部のLinuxシステムです。しかも、OpenSSHのセキュアシェルデーモンをPAM（Pluggable Authentication Modules）なしで稼働させ、パスワード認証を有効にしている環境に限られます。
これらの条件を満たし、さらに有効なパスワードハッシュを持つアカウントが少なくとも1つ存在する場合、257～1,024文字のパスワードを送ることで、本来パスワードを受け付けないはずのアカウントにアクセスされる可能性があります。対象は、rootや鍵認証専用のデプロイ用ユーザー、LDAPユーザーなどです。こうしたアカウントはパスワード欄にアスタリスク（*）が設定されている必要があります。なお、rootへの直接ログインは引き続きOpenSSHの設定に従います。
限定的な話に聞こえるかもしれませんが、実はそうではありません。
musl libcは省リソースであることから、組み込みLinuxシステムで広く使われています。さらに重要なのは、AWSとAzureの両方で公式クラウドイメージが提供されているAlpine Linuxの標準C ライブラリでもあることです。そのため、これらの環境で動作するAlpineシステムの一部は、設定によっては脆弱な可能性があります。
*sshole誕生の経緯
musl系LinuxにおけるOpenSSHのこの脆弱性は2016年にさかのぼります。しかしKültekin氏によると、そのルーツははるか昔、BSD Unixの時代にまで遡るといいます。
1980年、Sun Microsystemsの共同創業者でBSD Unixの重鎮でもあるBill Joy氏は、BSD Unixの開発に携わっていました。そのパスワードファイルでは、daemonユーザーの/etc/passwdエントリにアスタリスクが1つだけ記されていました。このアスタリスクはパスワードハッシュではなく、そのアカウントのパスワード認証を事実上無効にするものでした。
現在、パスワードハッシュは通常/etc/shadowに保存されています。システムはこのハッシュ情報を使って、ユーザーが入力した平文パスワードを検証します。パスワードログインを受け付けないアカウントには、今もアスタリスクが設定されています。しかしKültekin氏が調査報告で説明しているように、これは侵入を確実に防ぐ手段とは言えません。
保存された値と比較するためのパスワードハッシュを生成するcrypt()関数は、ハッシュを計算できない場合にNULLを返すことがあります。この戻り値を確認しないアプリケーションはクラッシュしかねません。そこでmuslの開発者は、特定の失敗時にNULLではなく1文字を返す設計を選び、その文字にアスタリスクを採用しました。
muslはほぼ同時期にSHA-512ベースのパスワードハッシュにも対応しました。Kültekin氏によれば、この処理はパスワードが長いほど遅くなります。極端に長いパスワードをサーバーに大量に送り付けられると、サービス拒否（DoS）につながる恐れがあります。muslはパスワードの上限を256バイトに設定しましたが、この先の展開はお察しのとおりです。
2016年、OpenSSHはSSH経由で有効なアカウント名を列挙されるのを防ぐ対策を導入しました。それ以前のsshdは、存在しないユーザーへの認証試行を、有効なアカウントへの試行よりも素早く拒否していました。有効なアカウントの場合は、拒否する前に入力されたパスワードをハッシュ化する必要があり、時間がかかっていたためです。そこで、無効なユーザーに対してもsshdがダミーのパスワードハッシュ処理を行う対策を採りました。適切なハッシュアルゴリズムとソルトを使い、応答時間の差を減らす仕組みです。
影響を受けるmusl系Linuxシステムでは、パスワードハッシュの代わりにアスタリスクが設定されたアカウントが、256バイトを超えるパスワードで突破される恐れがありました。この欠陥は2016年にさかのぼります。次の条件をすべて満たすmusl系Linuxシステムは、*ssholeの攻撃を受ける可能性があります。OpenSSHがPAMなしで動作している、パスワード認証が有効である、アスタリスクが設定されたアカウントが少なくとも1つある、有効なパスワードハッシュを持つ別のアカウントがある、という条件です。
幸い、OpenSSHは迅速にこの問題を修正しました。木曜日にリリースされたOpenSSH 10.6p2以降のビルドであれば保護されています。影響を受けるシステムでOpenSSHを更新できない場合は、パスワード認証を無効にしてSSHデーモンを再起動すれば問題ありません。
脆弱なシステムが悪用された形跡は確認されていません。ただ、確認したい場合に備え、Kültekin氏は調査報告に簡単なCLIコマンドを掲載しています。重要なマシン上でパスワードなしのアカウントが最近パスワードを受け付けたかどうかを調べられます。 ®
