Ing. Calogero Bono
2026年11月5日、*sshole と名付けられたバグを修正したOpenSSH 10.6p2がリリースされました。muslライブラリを使うLinuxのSSHサーバー、つまりAlpine Linuxなどが対象で、PAMは無効になっている場合に限られます。SSHポートに接続できる攻撃者は、非常に長いパスワードを送るだけでパスワードなしでアカウントに入れてしまいます。接続さえできれば攻撃できる点、そしてAlpineの公式クラウドイメージではrootアクセスが与えられる場合がある点が重要です。
事実に入る前に、いくつかの用語を確認しておきましょう。 muslは、Alpine、OpenWrt、Buildroot、Yoctoで使われる、glibcの代替となるC言語ライブラリです。crypt()は、パスワードをそのハッシュに変換する関数です。PAMは、Linuxのモジュール式認証システムです。/etc/shadowは、パスワードのハッシュを保存するファイルです。doasは、sudoに似た、root権限を得るためのツールです。
*ssholeバグはどのように機能するのか？
パスワードを持たないLinuxアカウントは、/etc/shadowのハッシュの代わりに*が入っています。本来、どのパスワードでもそのアカウントには入れないはずです。BleepingComputerによれば、2016年のOpenSSHの変更は、ユーザー列挙に関するCVE-2016-6210を修正するためのものでしたが、これによりこうしたアカウントに対してもハッシュの計算が行われるようになりました。
ここでmuslが関わってきます。Alpineの注意書きによれば、muslのcrypt()は鍵が256バイトを超えるとエラー信号として*を返します。このアスタリスクはアカウントに保存されたものと一致するため、比較が成功してしまいます。研究者のÖzgün Kültekinは、この欠陥は2016年から存在すると述べています。
本当に影響を受けるのは誰か？
複数の条件が同時に満たされる必要があります。Alpineによれば、openssh-serverパッケージはPAMなしでコンパイルされているか、openssh-server-pamをUsePAM noで使っている必要があります。PasswordAuthenticationは、デフォルトどおり有効でなければなりません。*のアカウントと、$5$または$6$のハッシュを持つ別のアカウントの両方が必要です。パスワードを持つユーザーが1人でもいれば、他のすべてのアカウントにも到達可能になります。
Alpineは、3.21から3.24およびedge、さらに古い3.16から3.20までのバージョンを検証しました。sshdを含まないコンテナ、PasswordAuthentication noのシステム、PAMが有効なシステムは影響を受けません。BleepingComputerによれば、glibcを使うDebian、Ubuntu、Fedoraは脆弱ではありません。
Alpineのクラウドイメージが心配される理由は？
公式のtiny-cloudイメージ、3.18.11から3.24.3までには、パスワードが*のalpineユーザーと、パスワードなしでdoasが使えるという設定があります。Alpineは、初回起動時点では安全だと説明しています。しかし、管理者がコンソールのパスワードを設定した場合や、user-dataでhashed_passwdを指定してユーザーを追加した場合など、$6$のハッシュが現れると悪用可能になります。
その時点で攻撃者はalpineとしてシェルを得て、doasによってrootになれます。PasswordAuthentication noを設定するcloud-initで構成されたイメージは影響を受けません。rootについては、デフォルトのPermitRootLogin prohibit-passwordが直接のログインから守ってくれますが、その保護は限定的です。
どのように修正し、攻撃の痕跡を確認するか？
修正はOpenSSH 10.6p2に含まれています。Alpineではapk upgrade -U -aを実行したあと、sshdを再起動してください。更新だけでは実行中のデーモンは置き換わらないためです。Alpineは、サポートが終了したリリースを含め、3.16まで修正済みのパッケージを公開しました。
更新できない場合は、PasswordAuthentication noを設定してsshdを再起動し、その前に鍵でのアクセスが機能することを確認してください。痕跡を探すには、/var/log/messagesで、パスワードを持たないアカウントに対する「Accepted password」の行を確認します。Alpineは、アクセスを排除できない場合には、そのマシンは侵害されたものとみなすべきだと付け加えています。アカウントの権限については、Linuxのパーミッションに関するガイドも参考になります。
知っておくべき制限
Alpineは、公開時点では CVE が割り当てられていないと明記しています。OpenSSHは、原因はsshdの外にあるものの、sshdを通じて悪用可能であり、そこで回避されてしまうと記しています。現時点で実際の攻撃が行われているというデータはありません。AIエージェントによる17,600件のテストに関する主張は、研究者によるもので、BleepingComputerが伝えたものであり、独立した検証はされていません。
デジタル分野で働く人にとっての変化
Alpineのサーバー、OpenWrtのルーター、YoctoやBuildrootを使った組み込みシステムを管理している場合は、sshdがパスワード認証を許可しているか、そして*のアカウントが存在するかを確認してください。多くの人はsshdを含まないコンテナでAlpineを使っており、その場合は影響を受けません。tiny-cloudイメージを使ったクラウドマシンを運用している場合は、すでに稼働しているすべてのインスタンスを確認する必要があります。定期的に更新される管理型サーバーであれば、この種のリスクは減らせます。詳しくはホスティングと管理型サーバーのページで扱っています。関連するAI生成エクスプロイトの件も、この記事で取り上げていますので、あわせてご覧ください。
私たちの見解
この事例は、互いに信頼し合うコンポーネントの境界がいかに脆いかを示しています。OpenSSHは2016年に正当な防御策を追加し、muslは一般的なエラー値を選びました。その組み合わせにより、10年間にわたって穴が開いていたことになります。また、このバグがAIエージェントによって発見されたことも気になる点です。OpenSSH自身も、AIで見つかったバグは他の人にも再発見されやすいと警告しており、待つことにはリスクがあります。最も確実な対策は、昔から変わらず、パスワードの代わりに鍵を使うことです。
よくある質問
DebianやUbuntuも*ssholeの影響を受けますか？
いいえ。これらはglibcを使っており、muslライブラリは使っていません。BleepingComputerによれば、PAM認証を使うシステムは脆弱ではありません。ただしAlpineは、openssh-server-pamでUsePAM noの場合は影響がなく、UsePAM yesの場合は影響がないとは言えないと注意しています。
opensshパッケージを更新するだけで十分ですか？
いいえ、sshdの再起動も必要です。Alpineによれば、パッケージの更新では実行中のデーモンは置き換わらないため、脆弱なバージョンが動き続けてしまいます。
更新せずに自分を守る方法はありますか？
一時的な対策としては可能です。sshdの設定でPasswordAuthentication noを指定し、サービスを再起動してください。事前に鍵による接続が機能することを確認しておいてください。
rootアカウントも狙われますか？
場合によります。デフォルトのPermitRootLogin prohibit-passwordの設定では、rootへの直接のログインはできません。ただしPermitRootLogin yesが有効になっている場合や、doasなどを通じて別のユーザーがrootになれる場合は危険です。
このバグにCVEはありますか？
Alpineによれば、まだありません。注意書きの執筆時点では、識別子は割り当てられていませんでした。参照先はOpenSSH 10.6p2のリリースノートです。
OpenSSH 10.6p2のあとに確認すべきこと
OpenSSHは、修正をより早くユーザーに届けるため、リリースの頻度を上げると発表しました。このバグには、今後も追うべき課題が残っています。
- CVEが割り当てられるかどうか、そしてスキャンツールがそれを認識するかどうかを確認してください。
- OpenWrt、Buildroot、Yoctoをベースにしたファームウェアの提供元が、いつ更新を公開するかを確認してください。
- 予定されたバージョンを待たずにOpenSSHのマイナーリリースを導入できるよう、手順を準備しておいてください。
