256文字超のパスワードでSSH認証突破 muslのバグ「*sshole」が話題
姉妹サイトの新着
海外の技術者向けサイト「Hacker News」で、SSH認証に関する脆弱性レポート『*sshole』が話題になっていた。musl libcのcrypt()関数は、256文字を超えるパスワードを渡された際に本来失敗とすべき処理を「常に成功扱い」にしてしまう仕組みになっており、musl libc・PAM未使用・OpenSSHでパスワード認証有効という条件が重なるとSSH認証を通過できてしまう可能性があるという。スレッドでは実際に再現できたかどうかや、どんな環境がこの条件に当てはまるのかをめぐって議論が交わされた。
*sshole(名前の由来は後述の議論で触れられている、musl libcのcrypt()関数に起因するSSH認証バイパスの脆弱性レポート)
出典: sshhole.com / 元記事はこちら
何よりがっかりなのは、muslの開発者たちが暗号処理の核心部分に『まあ便利だから』という理由で色々と変更を加えてきたことだ。しかも今回のバグを検出できるレベルの監査もせずに。この件で自分の中でのmuslへの評価が少し下がった。
>>3
『少し』?! 言わせてもらうと、muslは正直ジョークみたいなものだ。今回の件もその証拠の一つに過ぎない。これだけ警告サインが出ていたのに、なぜ本番環境で使う人がいるのか理解できない。使っている側の自己責任だと思う。
『少し』?! 言わせてもらうと、muslは正直ジョークみたいなものだ。今回の件もその証拠の一つに過ぎない。これだけ警告サインが出ていたのに、なぜ本番環境で使う人がいるのか理解できない。使っている側の自己責任だと思う。
実際に再現できた人はいる? 公式のAlpine Dockerイメージで試して、rootのパスワードログインを有効にしてみた。shadowのパスワード欄はデフォルトで`!`になっていて、256文字超のパスワードでは成功しなかった(`passwd -l`でも同じく`!`になる)。手動で`*`に変えてみても駄目だった。何かやり方を間違えているんだろうか? OpenSSH_10.3p1, OpenSSL 3.5.9(2026年9月29日), PRETTY_NAME="Alpine Linux v3.24"
>>4
いや、自分のFirecracker VM(そもそも外部に公開してないやつ)では再現できなかった。
いや、自分のFirecracker VM(そもそも外部に公開してないやつ)では再現できなかった。
>>4
自分の理解では、デフォルト設定では動かないはず。musl-libc、PAMなし、OpenSSHの組み合わせが必要。
自分の理解では、デフォルト設定では動かないはず。musl-libc、PAMなし、OpenSSHの組み合わせが必要。
>>4
先に普通の長さの間違ったパスワードで一度ログイン失敗させてから試した?
先に普通の長さの間違ったパスワードで一度ログイン失敗させてから試した?
よく作り込まれたサイトだとは思うけど、特に何の感情も湧かないな。
>>5
それは君の感性の問題かもね。自分は普通に楽しめた。ただ`*sshole`という名前と`sshhole.com`というドメインで`h`の数が違うのが気になって仕方なかった。これを見つけて書き上げるくらいこだわる人が、なぜ`h`の数を揃えることにはこだわらなかったのか[0]。
[0]: 人間であれLLMであれ、あるいはその両方が混ざった存在であれ。差別も判断もしない。
それは君の感性の問題かもね。自分は普通に楽しめた。ただ`*sshole`という名前と`sshhole.com`というドメインで`h`の数が違うのが気になって仕方なかった。これを見つけて書き上げるくらいこだわる人が、なぜ`h`の数を揃えることにはこだわらなかったのか[0]。
[0]: 人間であれLLMであれ、あるいはその両方が混ざった存在であれ。差別も判断もしない。
>>5
LLMの文章に慣れすぎて感覚が麻痺してるだけじゃない?
LLMの文章に慣れすぎて感覚が麻痺してるだけじゃない?
>>5
死んだものは二度死なない。今のブルーチーム(防御側)は皆アイアンボーンみたいなものさ。
死んだものは二度死なない。今のブルーチーム(防御側)は皆アイアンボーンみたいなものさ。
OpenWRTやAsusWRTなどは、デフォルトでOpenSSHじゃなくdropbear sshを使っているはず。それなら今回の影響は受けないんじゃないかな?
実際にmuslを使い、PAMなしで、パスワード認証を有効にしたOpenSSHのsshdを動かしているものって何があるんだろう? あくまで『実在するもの』の話として。Alpineという仮定の存在は分かるけど、実際にそんな構成で動かしているところはどこ?
>>7
大量のDockerコンテナじゃない?
追記: 確かにこの条件でsshdを動かしているのは少数派だろう。でも『少数派』×『世界中で動いているAlpineコンテナの数』をかけると、絶対数としてはかなり多くなる。
追記2: 実際、ダウンロード数百万規模の公開コンテナの例は探すのにそんなに苦労しない。
大量のDockerコンテナじゃない?
追記: 確かにこの条件でsshdを動かしているのは少数派だろう。でも『少数派』×『世界中で動いているAlpineコンテナの数』をかけると、絶対数としてはかなり多くなる。
追記2: 実際、ダウンロード数百万規模の公開コンテナの例は探すのにそんなに苦労しない。
>>40
sshdを動かしているDockerコンテナなんてあるの?
sshdを動かしているDockerコンテナなんてあるの?
>>40
Dockerコンテナでsshdを動かしてるの?
Dockerコンテナでsshdを動かしてるの?
ハハ、すごいな。見つけたのも書き方も素晴らしい。
うわ。10年前の一般的なファザーでも見つけられたんじゃないかこれ。256文字超のパスワードなら本当に何でも通ってしまうなら、musl上のOpenSSHは誰もファジングしてこなかったということになる。
別スレの出典[1]によると、PAMなしのmuslで影響がある。`PasswordAuthentication=no`に設定するか、更新すれば対処できる。
[1] https://hachyderm.io/@damienmiller/117563026759098135
[1] https://hachyderm.io/@damienmiller/117563026759098135
多くのLinuxサーバーソフトが実際には『Linux + systemd』を前提に作られていると知ってから、Alpineベースのコンテナは避けるようにしている。LinuxとsystemdのAPIを合わせた集合が、今では事実上の『Linux API』になっている気がする。
>>11
自分はできる限りAlpineベースのコンテナを使うようにしている。systemdがLinuxを腐らせるのを少しでも防ぐためだ。sshdを有効にしたことは……あ、PostmarketOSを入れてるPineBook Proでは有効にしてた。やべえ。
自分はできる限りAlpineベースのコンテナを使うようにしている。systemdがLinuxを腐らせるのを少しでも防ぐためだ。sshdを有効にしたことは……あ、PostmarketOSを入れてるPineBook Proでは有効にしてた。やべえ。
これはちょっと衝撃的だ。AI関連の脆弱性発見の波はまだ続いているんだな。
このバグと、それを『修正』したコミットを見ると、muslの管理体制がかなりグダグダなのが分かる。どのプロジェクトにもバグはあるものだけど、ここでなぜ車輪の再発明をしたのか疑問に思ってしまう。あちこちで足を踏んでいる印象。
A+な名前だな。
>>17
A*(エースター)な名前、ね。
A*(エースター)な名前、ね。
これの本当の名前は『*sshole』で、結局『*』(アスタリスク)がこの話の主役というわけだ。
>>21
`*sshole`、つまり`*`が主役ってことね。ちなみに`\`でエスケープすればマークダウンの強調表示を防げるよ。
`*sshole`、つまり`*`が主役ってことね。ちなみに`\`でエスケープすればマークダウンの強調表示を防げるよ。
このサイトが脆弱性を分かりやすく説明していたのが良かった。
>>23
自分には全然理解できなかった。スクロールや画像がやたら気を散らして、集中できない。
自分には全然理解できなかった。スクロールや画像がやたら気を散らして、集中できない。
`FROM scratch`(実質何も入っていないベース)から自分でDockerイメージを作る、また一つ理由が増えたな。
>>24
いや、Alpineのコンテナにsshdは最初から入っていない。Dockerfileで手動インストールして、しかも設定をそのままにしておかないとこうはならない。
いや、Alpineのコンテナにsshdは最初から入っていない。Dockerfileで手動インストールして、しかも設定をそのままにしておかないとこうはならない。
>>24
コンテナの中でsshdを動かす人なんていないでしょ、少なくともそう願いたい。docker execやkubectlが使えるのに、わざわざsshdを動かす意味がある?
コンテナの中でsshdを動かす人なんていないでしょ、少なくともそう願いたい。docker execやkubectlが使えるのに、わざわざsshdを動かす意味がある?
他サイトの新着
>>12
パスワード認証が鍵認証より弱いって、具体的にはどういうこと? 認証コードのバグはどちらの経路でも起こりうる。極端に短いパスワードでなければ、総当たり耐性としてはどちらも同じくらい強いはず。つまり概念的には、鍵もパスワードの一種と言えるんじゃないか?
パスワード認証が鍵認証より弱いって、具体的にはどういうこと? 認証コードのバグはどちらの経路でも起こりうる。極端に短いパスワードでなければ、総当たり耐性としてはどちらも同じくらい強いはず。つまり概念的には、鍵もパスワードの一種と言えるんじゃないか?
>>43
鍵は自分の端末から外に出ない、という違いがある。
鍵は自分の端末から外に出ない、という違いがある。
>>12
このバグは、パスワード認証をオフにしていても発生する。
このバグは、パスワード認証をオフにしていても発生する。
>>44
どこからそんな考えが出てきたの? このバグは丸ごとパスワードハッシュに関するものだ。パスワード認証がオフなら、そもそもその処理自体が実行されない。
どこからそんな考えが出てきたの? このバグは丸ごとパスワードハッシュに関するものだ。パスワード認証がオフなら、そもそもその処理自体が実行されない。
>>44
『パスワード認証をオフにしていても発生する』って、本当に? 別の人はさっき『PasswordAuthentication=noにするか更新すれば対処できる』と言っていたけど。うちの職場ではmuslを使っていないので、自分で検証する手段がない。
『パスワード認証をオフにしていても発生する』って、本当に? 別の人はさっき『PasswordAuthentication=noにするか更新すれば対処できる』と言っていたけど。うちの職場ではmuslを使っていないので、自分で検証する手段がない。
>>19
『残念ながら、cryptを呼び出すプログラムの多くは、その失敗に対応できておらず、使う前に戻り値がnullでないかを確認していない。そのため、常に“成功”させつつ、絶対に一致しないハッシュを返す方が、エラーで失敗させるよりも良い挙動だと言われている』[1]
[1] https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70f…
『残念ながら、cryptを呼び出すプログラムの多くは、その失敗に対応できておらず、使う前に戻り値がnullでないかを確認していない。そのため、常に“成功”させつつ、絶対に一致しないハッシュを返す方が、エラーで失敗させるよりも良い挙動だと言われている』[1]
[1] https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70f…
>>47
なんとも疑わしい判断だ!『呼び出し側がnullを正しく処理できずクラッシュするバグを表面化させるより、黙らせて呼び出し側が正しいことにしてしまおう。一部の状況で衝突が起きる(今回の脆弱性の原因になった)方が、クラッシュするよりマシだ』ということらしい。自分の『大声で失敗せよ』という主張(https://alejo.ch/3gk)に、この件を実例として追加しようかな。
なんとも疑わしい判断だ!『呼び出し側がnullを正しく処理できずクラッシュするバグを表面化させるより、黙らせて呼び出し側が正しいことにしてしまおう。一部の状況で衝突が起きる(今回の脆弱性の原因になった)方が、クラッシュするよりマシだ』ということらしい。自分の『大声で失敗せよ』という主張(https://alejo.ch/3gk)に、この件を実例として追加しようかな。
>>36
よく見て。2つ目の`h`は文字の後ろに隠れていて、背景とほぼ同じ色になってる。
よく見て。2つ目の`h`は文字の後ろに隠れていて、背景とほぼ同じ色になってる。
>>57
ああ、本当だ。ありがとう!
ああ、本当だ。ありがとう!
この話題の背景と論点
今回の脆弱性は、Cの標準ライブラリの一つであるmusl libcが提供するcrypt()関数の仕様に起因する。cryptは本来、処理に失敗した場合にNULLを返す仕様だが、呼び出し元の多くがNULLチェックを行わず異常終了してしまうため、musl側は「失敗時は絶対にマッチしないダミーのハッシュを返す」という設計にしていた。256文字を超える長大なパスワードを渡した際にこの分岐が働き、結果的に認証が通ってしまう組み合わせが生まれたとされる。スレッドでは、実際に再現できる条件が「musl libc・PAM未使用・OpenSSHでパスワード認証が有効」という狭い構成に限られる点や、パスワード認証自体を無効化していれば影響を受けないという誤解の訂正などが交わされ、技術的な論点と実害の範囲についての認識のずれが見られた。
※本記事は海外掲示板 Hacker News のスレッド「Sshole」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。