Japanese Translation:

musl ベースの Linux 分布（Alpine、OpenWrt、Buildroot、Yocto など）に実装されている OpenSSH は、パスワード認証が有効化されていながら PAM が使用されていない環境におけるシステムで重大なセキュリティ欠陥を有しています。この脆弱性により、攻撃者が 256 文字を超える長さのパスワードを提供した場合、

/etc/shadow

ファイル内で

を設定したアカウント（例：root、LDAP ユーザーなど）に対するパスワードチェックを回避できます。この問題は、musl ライブラリの認証失敗処理に関する 2012 年の変更および、256 バイトを超える無権限な入力に対するハッシュ検証の特定の動作に起因しています。新規で既存のパスワードのないシステムには影響はありませんが、これらの分布を運用する組織は、アカウント乗っ取りの重大なリスクに直面しています。この即座の脅威に対処するためには、管理者は OpenSSH バージョン 10.6p2 にアップグレードするか、あるいは完全にパスワード認証を無効化する必要があります。なお、この脆弱性は主に PAM が利用されていない環境に影響を与えるものであり、PAM を使用している場合、標準的なハンドリングによりこの特定の攻撃ベクトルを防ぐ可能性があります。この問題に対処しないことは、以前に誤設定されたアカウントに関連した主要なインシデントと同程度の不正アクセスにつながりかねません。

256 バイト以上のパスワードを受け付けてしまうセキュリティ脆弱性

Alpine Linux や OpenWrt、Docker イメージなどで広く使用されている musl ライブラリは、2016 年以来長年、深刻なセキュリティ上の不具合を抱えていました。本来はパスワードを設定すべきではないアカウント（root ユーザー、SSH キー認証専用ユーザーなど）に対し、256 バイトより長いパスワードを受け付けてしまうという問題です。

歴史的背景：なぜ「*」なのか？

1980 年：最初の星号

古い Unix システムではパスワードが

/etc/passwd

に平文で保存されていました。

ビル・ジョイは、ログイン不可のアカウント（
```
daemon
```
）に対し、パスワードとしてアスタリスク
```
*
```
を設定しました。
```
*
```
はハッシュ値ではないため、マッチングすることはありません。現代でもこの仕組みは維持されています。
- 参照: 3BSD /etc/passwd

1990 年代：sshd の認証と crypt()

現代ではパスワードハッシュは

/etc/shadow

に格納され、

$6$...

(SHA512) の形式になります。

正常なケース: ユーザー入力 → ハッシュ化 → 保存値と比較 → ログイン成功/失敗
星号のケース: フィールドが
```
*
```
なら、マッチング対象がないためログイン不可

crypt() 関数の仕様（1997）

Single Unix Spec では、

crypt()

が計算できない場合（サポートされていないアルゴリズムなど）は NULL を返すと定義されています。

しかし多くのプログラムは NULL チェックを行わず、比較時にクラッシュしていました。

2012 年：musl の対応変更

Alpine で使用される musl C ライブラリが仕様を変更しました。

変更内容:
```
crypt()
```
は失敗しても NULL を返しなくなり、代わりに単一の文字を返すようにしました。
選ばれた文字: アスタリスク *
- コミット: b3c4cc12
- 理由: "報告された通りである"（NULL でクラッシュするリスク回避）

2012 年：SHA512 クリプトの追加と制限

musl は SHA512 を実装しましたが、パスワードが長ければ長いほどハッシュ化に時間がかかるため、サーバーへの攻撃を容易にしました。

対策: パスワード長を 256 バイト で制限。それ以上は拒否。
致命的な不具合: SHA512 クリプトが失敗すると、前述のように
```
crypt
```
は
```
*
```
を返す仕様です。
- コミット: 88bf5a8a (変更から 20 日後)
- 結果: 256 バイト超のパスワードを受け付けた場合、システムは
```
*
```
  を返すことで「ログイン拒否」と判断してしまうが、実際にはハッシュ化すらされない状態に陥る。

脆弱性の連鎖：2016〜2026

2016 年：CVE-2016-6210（タイミング攻撃）

sshd は、存在しないユーザーへの問い合わせは即時返答、実在ユーザーには数ミリ秒遅れて返答するため、ユーザー名の列挙が可能でした。

対策: ユーザーが存在しない場合やハッシュ化できない（
```
*
```
のような）場合でも、別のアカウントのソルトを使って時間稼ぎをし、応答を遅らせます。
問題点: この「遅延」は、パスワードが
```
*
```
である実在ユーザーにも適用されるようになり、セキュリティ監査に誤解を与えました。

2019〜2022 年：Alpine の root アカウント修正

Alpine Linux は CVE-2019-5021 で root パスワード未設定を発見し対応しました。

2019 年: root を
```
!
```
でロック。しかし PAM を使わない環境では SSH キー認証も無効化される問題発生。
2022 年 (Alpine 3.16): root のパスワードを *
に変更し、ロック状態を保ちつつキー認証を再開。

静的な十年：誰も気づかなかった理由

なぜこの問題は長年にわたり見過ごされたのか？

```
crypt()
```
が
```
*
```
を返すのは musl の実装振る舞いであり、OpenSSH や glibc では直接テストされていませんでした。
PAM モジュールを介している環境では、
```
*
```
に対して直接
```
crypt()
```
を呼び出さないため問題が発生しませんでした。
```
/etc/shadow
```
に
```
*
```
が存在するのは「誤作動」や「長すぎるパスワード試行」の後に限られるため、初期状態での攻撃対象になり得ないと判断されました。

脆弱性の概要：私たちが直面した問題

OpenSSH の認証コードを調査中に、約 17,600 回の奇妙なログイン試行を行い、以下の事実を確認しました。

対象: musl を使用し、PAM を使用しない sshd（Alpine 標準など）。
現象: 許容されないパスワード（256 バイト超の文字列）を受け付け、「許可」したように振る舞う。
- 原因:
```
crypt()
```
  が失敗して
```
*
```
  を返すため、sshd がこれを「ハッシュ値が一致しない＝拒否」と誤判断し、結果として認証プロセスが完了してしまう不整合があった。

TL;DR：被害状況と対策

ご自身の環境に被害はありませんか？

以下の条件を満たす場合、257 バイトから 1024 バイトまでのあらゆるパスワードを受け付けてしまいます。

musl を使用しているか？ (Alpine Linux, OpenWrt, Buildroot, Yocto など)
PAM を使用していないか？ (
```
/etc/shadow
```
にあり、
```
UsePAM no
```
の設定)
パスワード認証が有効か？
パスワードフィールドが
*
であるアカウントがあるか？
- 例：Alpine の root ユーザー、LDAP ユーザー、キー認証専用ユーザーなど。

被害対象例:

Alpine 公式の AWS/Azure イメージ: デフォルトユーザーが該当し、パスワード不要で
```
doas
```
を使えるため、実質的に root 権限を不正取得できてしまう可能性があります。
Debian/Ubuntu/Fedora: PAM を経由しているため影響なし。
Dropbear/OpenBSD: 影響なし。

次に何をするか（修正手順）

1. パッケージを更新する（推奨）

OpenSSH 10.6p2 でこの問題が修正されています。

# Alpine の場合
apk upgrade openssh

# その他の musl ベースのシステム
sudo apt update && sudo apt install --only-upgrade openssh-server # Debian系の場合など

2. 更新ができない場合（即時対策）

パスワード認証を無効化します。

# パスワード認証を無効化する設定を追加
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf

# サービス再起動
rc-service sshd restart
# または systemd 系の場合
systemctl restart sshd

3. ハッキングされていないか確認する

root ユーザーがパスワードなしでログイン可能になっているか、以下のリポジトリを参照してください。

github.com/oz9un/sshole
- ```
root@your-box
```
  と表示されれば、脆弱性が存在することを示唆します。

もし既にハッキングされていたら…

ご安心ください。これは既知の問題であり、上記の更新または設定変更で回避可能です。ただし、重要なデータへのアクセス権限を失くした場合は、リセット作業が必要になる場合があります。

SSH ホール