Chaînes de filtres PHP : transformer une inclusion locale de fichier en exécution de code à distance

L'inclusion locale de fichier (LFI) est souvent traitée comme un bug de lecture seule. Un attaquant peut lire /etc/passwd, peut-être du code source, et l'histoire s'arrête là. Les chaînes de filtres PHP ont changé ce calcul. En abusant de php://filter avec une séquence soigneusement construite de transformations convert.iconv, un attaquant peut synthétiser des octets arbitraires dans un flux — y compris une charge utile PHP valide — sans téléverser de fichier ni écrire sur disque. Combiné à un point d'inclusion, le résultat est l'exécution de code à distance.

---

1. Le point d'inclusion

Un schéma vulnérable classique passe un paramètre de requête directement à include ou require :

<?php
// vulnerable.php
$page = $_GET['page'] ?? 'home';
include(__DIR__ . '/pages/' . $page . '.php');

Un attaquant qui contrôle page peut remonter les répertoires (../../etc/passwd) ou, si les wrappers URL sont activés, fournir un wrapper comme php://filter. Le suffixe .php est ajouté, mais les wrappers et la normalisation peuvent encore produire un comportement utile selon le code. La démonstration la plus claire utilise une inclusion sans suffixe :

<?php
include($_GET['file']);

---

2. Ce que fait php://filter

php://filter applique des filtres de flux à une ressource. Un exemple simple lit un fichier et le décode en base64 :

php://filter/convert.base64-decode/resource=/var/www/html/config.php

Les filtres peuvent être chaînés. Chacun transforme le flux avant que le suivant ne le reçoive. Les filtres convert.iconv.* convertissent entre encodages, et certains encodages ont des séquences d'échappement avec état qui produisent des octets précis. En les chaînant, les chercheurs ont pu préfixer un flux avec des données contrôlées.

---

3. La technique Synacktiv

Synacktiv a publié un générateur qui construit une chaîne de filtres produisant un préfixe arbitraire. La chaîne part d'une charge utile encodée en base64 et utilise une séquence de conversions iconv pour émettre les octets voulus au début du flux. L'URL générée ressemble à ceci (tronquée) :

php://filter/convert.iconv.UTF8.CSISO2022KR|convert.base64-encode|...|convert.base64-decode/resource=php://temp

Le générateur automatise la recherche d'une chaîne produisant la charge exacte. En laboratoire :

# Installer le générateur dans un lab isolé
git clone https://github.com/synacktiv/php_filter_chain_generator
python3 php_filter_chain_generator/php_filter_chain_generator.py \
  --chain '<?php system($_GET["c"]); ?>'

L'outil affiche une URL php://filter/.... La passer à l'include vulnérable amène PHP à compiler et exécuter la charge synthétisée. La charge ne touche jamais le disque, ce qui contourne les restrictions d'upload, les contrôles d'extension et de nombreux moniteurs d'intégrité.

N'utilisez cette technique que dans des évaluations autorisées et des laboratoires isolés. Le générateur et le bug sous-jacent sont puissants ; les exécuter contre des systèmes que vous ne possédez pas est illégal.

---

4. CVE-2024-2961 et le lien avec glibc

En 2024, Ambionics a publié des recherches sur une vulnérabilité iconv de glibc suivie comme CVE-2024-2961. Il s'agit d'une écriture hors limites dans la gestion du jeu de caractères ISO-2022-CN-EXT, affectant glibc avant 2.40. Elle peut être déclenchée via les filtres iconv de PHP et, dans les bonnes conditions, corrompre la mémoire et exécuter du code.

Pour le LFI, la technique des chaînes de filtres n'a pas toujours besoin d'une primitive propre de « synthèse d'une balise PHP ». Un bug de corruption mémoire dans la bibliothèque de conversion offre un autre chemin d'une primitive de lecture à l'exécution. L'exploit exact dépend de la version PHP, de la build glibc et de l'état de l'allocateur ; c'est pourquoi la recherche était notable : elle transformait une classe de bugs « lecture seule » en chaîne RCE fiable sur de nombreuses distributions.

PHP 8.5 est sorti le 20 novembre 2025. Les organisations doivent vérifier ensemble leurs versions PHP et glibc ; mettre à jour l'une sans l'autre peut laisser le chemin de conversion vulnérable accessible. Le correctif durable est de supprimer le point d'inclusion, pas d'espérer que la chaîne échoue.

---

5. Pourquoi cela contourne les défenses courantes

• Aucun upload requis. La charge est générée en mémoire ; les répertoires d'upload, contrôles MIME et antivirus ne la voient jamais.
• Aucun répertoire inscriptible requis. L'attaquant n'a pas besoin de déposer un webshell.
• Les règles WAF par signature peinent. L'URL est une longue chaîne de noms de filtres légitimes ; bloquer toutes les variantes est difficile sans bloquer l'usage légitime.
• La charge peut être courte. Une balise PHP suffit pour appeler system, assert ou une fonction personnalisée.

---

6. Détection et durcissement

6.1 Supprimer les inclusions dynamiques

Ne passez jamais d'entrée utilisateur directement à include, require, include_once ou require_once. Utilisez une table d'autorisation :

<?php
$pages = [
    'home' => __DIR__ . '/pages/home.php',
    'about' => __DIR__ . '/pages/about.php',
    'contact' => __DIR__ . '/pages/contact.php',
];

$key = $_GET['page'] ?? 'home';
if (!array_key_exists($key, $pages)) {
    http_response_code(404);
    exit;
}
include $pages[$key];

Cela élimine le point d'inclusion. Aucune chaîne de filtres, astuce d'encodage ou traversée ne peut sélectionner un fichier hors de la table.

6.2 Durcir la configuration PHP

• Réglez allow_url_include = Off et allow_url_fopen = Off sauf besoin explicite.
• Utilisez open_basedir pour restreindre l'accès au répertoire de l'application.
• Désactivez les wrappers inutilisés lorsque le runtime le permet.
• Exécutez PHP en utilisateur à faible privilège, sans accès shell et sans écriture hors du répertoire d'upload.

6.3 Corriger la pile de conversion

Maintenez glibc en 2.40 ou plus sur les distributions affectées, et PHP à jour. Suivez CVE-2024-2961 dans votre gestion des vulnérabilités même si l'application n'utilise pas iconv directement ; le système de filtres PHP peut l'atteindre.

6.4 Détecter la technique

Journalisez les paramètres contenant php://filter, des jetons convert.iconv répétés ou des query strings anormalement longues. Alertez sur les erreurs d'inclusion révélant l'usage de wrappers. Une règle WAF peut bloquer les chaînes évidentes, mais c'est une atténuation, pas un correctif.

# Exemple de détection dans les logs web (à valider avant déploiement)
grep -E 'php://filter|convert\.iconv' /var/log/nginx/access.log | head

---

7. Conclusion

Les chaînes de filtres PHP effacent la distinction entre « lecture de fichier » et « exécution de code ». Le point d'inclusion est la vulnérabilité ; la chaîne de filtres est le vecteur. CVE-2024-2961 a montré que même la bibliothèque de conversion peut devenir une primitive d'exploitation. La bonne réponse n'est pas de bloquer une chaîne de charge particulière mais d'éliminer les inclusions dynamiques, de contraindre le système de fichiers, de corriger le runtime et de surveiller l'abus des wrappers. Si une application peut être amenée à inclure un chemin choisi par l'utilisateur, supposez qu'un attaquant finira par transformer ce chemin en code.