LinuxのSSHログインは、鍵認証を使っていれば安全、という感覚を持ちやすい。ところが今回の話は、その前提をかなり嫌な形で崩している。musl libc を使う環境の OpenSSH で、2016年から一部の「本来はパスワードを受け付けないアカウント」に、長い文字列なら通ってしまう穴があったという。しかも Alpine Linux だけでなく、OpenWrt、Buildroot、Yocto、そして多くの Docker イメージにも関係する話だ。単なる珍しいバグではなく、普段の運用に紛れ込んで見逃されやすいタイプの不具合として読むべきだと思う。
元記事が伝えているのは、OpenSSH が musl Linux 上で動いているとき、ある条件のアカウントに対して「長いパスワード入力」が誤って受け入れられていた、という話だ。対象は root、鍵認証だけにしている deploy 用ユーザー、LDAP ユーザー、そして Alpine の AWS/Azure 公式イメージにあるデフォルトユーザーのように、そもそも通常のパスワードログインを想定していないアカウントだ。記事によれば、こうしたアカウントが 257 文字から 1024 文字の入力に対して通ってしまう。
背景には、昔からの Unix の流儀と、musl の crypt() 実装の癖が重なっている。Unix では昔、/etc/passwd にパスワードのハッシュを置いていたが、ログインさせたくないアカウントには * を入れて「絶対に一致しない印」にすることがあった。SSH は入力されたパスワードを crypt() でハッシュ化し、保存された値と比べる。ところが crypt() が失敗したとき、musl は NULL ではなく * を返すようにした。さらに SHA-512 系の crypt では、長すぎる入力を 256 バイトで打ち切る実装になっている。ここで失敗扱いになった結果として * が返り、保存値が * のアカウントと一致してしまう。
しかも 2016 年の OpenSSH の修正が、この問題を露出させた。CVE-2016-6210 への対策として、存在しないユーザーへの応答時間を一定にするため、sshd は別アカウントの salt を借りてハッシュ計算をするようになった。これ自体はタイミング攻撃への対処だったが、musl では「本来ならログイン不可の * アカウント」に対しても同じ経路が通り、長い入力だけが通る形になった。記事は、2026年に著者がいろいろな組み合わせで sshd をビルドして大量のログイン試行を流し込んだ結果、この挙動を見つけた、と説明している。対策としては、OpenSSH 10.6p2 への更新、または一時的にパスワードログインを無効にする設定が示されている。
私がまず引っかかったのは、このバグが「パスワードログインを使っている人だけ」の話ではない点だ。root や運用用アカウントは、鍵だけで入るようにしていることが多い。その前提のままでも、内部ではパスワード検証の経路が残っていて、そこに musl と OpenSSH の癖が噛み合うと、想定外の入口になる。つまり、設定を固くしたつもりでも、実装の隙間から入られる。こういう事故は、表向きの管理画面よりも、ライブラリの戻り値の扱いで起きやすいのだと思う。
元記事の面白いところは、256 文字という数字が二つの意味を持っていることだ。ひとつは、musl の SHA-512 crypt が長すぎる入力を切る境界。もうひとつは、その失敗が * を返すことで、* のまま保存されているアカウントと噛み合う点だ。普通なら「長すぎる入力は弾かれるから安全」と考えたくなるが、ここでは弾いた結果の失敗表現そのものが危ない。設計上はよくある防御策でも、他の層がその失敗をどう解釈するかで、まったく違う意味になる。私はこの手の問題を、単体のバグというより「失敗の表現がアプリケーション間で共有されてしまった事故」と見ている。
この話がやっかいなのは、対象が Alpine Linux だけに閉じないことだ。OpenWrt、Buildroot、Yocto も musl 系の利用が多いし、そこから作られた Docker イメージも少なくない。記事では、Alpine の公式 AWS/Azure イメージにある default ユーザーが、passwordless doas で実質 root 相当になりうるとも触れている。つまり、サーバー本体の管理者だけでなく、イメージを再利用している開発者や、コンテナでSSHを立てている人にも波及する。特に「公式イメージだから大丈夫」と思い込みやすい環境ほど、こうした穴は見つけにくいはずだ。
この記事を読んで少し怖いのは、著者が示すように「OpenBSD と glibc では通らず、musl の非-PAM 環境だけで起きる」ような、狭い条件に閉じた不具合だという点だ。しかも PAM を使っていれば crypt() 自体に届かないことが多いので、通常のディストリビューションでは見えにくい。つまり、広く使われている経路ではないからこそ、長年残る。私はここに、セキュリティ問題の本質があると思う。危ないのは派手な暗号アルゴリズムの破綻だけではない。もっと地味な「境界値」「戻り値」「例外処理」の噛み合わせが、何年も静かに残ることだ。運用側は、鍵認証の採用や PAM の有無、ベースイメージの libc まで含めて見直さないといけない。
