Contournement d'ASLR sans Fuite d'Information : Durcissement des Binaires et Exploitation de fork() sous Linux

<time datetime="2026-10-23">Vérifié le: 23 octobre 2026</time> · Ingénierie d'Exploitation : Linux x86_64 ASLR, PIE, glibc 2.35+

Depuis plus de deux décennies, la technologie de Randomisation de l'Espace d'Adressage (ASLR - Address Space Layout Randomization) constitue l'un des piliers défensifs les plus fondamentaux des systèmes d'exploitation modernes face aux vulnérabilités d'écrasement mémoire. Dans la théorie de sécurité offensive classique, réussir une exécution de code arbitraire (RCE) fiable sous Linux 64 bits sans disposer préalablement d'une fuite d'adresses mémoire (Information Leak) était considéré comme une quasi-impossibilité mathématique.

Pourtant, les vecteurs d'attaque développés contre PHP2Shell (CVE-2026-109618 et CVE-2026-109619) ont prouvé qu'il est possible de réaliser une exécution de commandes à distance en une seule requête (Single-Shot RCE) en contournant l'ASLR sans divulgation d'information préalable.

Dans cette étude, nous analysons les faiblesses architecturales inhérentes au modèle de processus multiprocesseurs de PHP-FPM et les variations de durcissement des paquets au sein des principales distributions Linux.

---

1. Matrice de Durcissement des Binaires selon les Distributions Linux

Les dépôts officiels des différentes distributions appliquent des options de compilation divergentes lors de la génération des binaires PHP. Le tableau ci-dessous synthétise la posture de sécurité (analysée via l'utilitaire checksec) et la faisabilité d'une attaque directe :

Distribution / Système	PIE (Position Independent Executable)	Stack Canary	Bit NX (Pile Non Exécutable)	RELRO (Relocation Read-Only)	Faisabilité RCE Direct sans Info-Leak
Ubuntu 22.04 / 24.04 LTS	Activé (Full PIE)	Activé	Activé	Full RELRO	Viable (Détournement de fork)
Debian 11 / 12	Activé (Full PIE)	Activé	Activé	Full RELRO	Viable (Détournement de fork)
RHEL 8 / 9 (Rocky / Alma)	Activé (Full PIE)	Activé	Activé	Full RELRO	Viable (Détournement de fork)
Alpine Linux (musl libc)	Activé (Full PIE)	Activé	Activé	Full RELRO	Complexe (Spécificités du tas musl)
Compilations Personnalisées	Désactivé (No PIE)	Activé	Activé	Partial RELRO	Critique / Exploitation Immédiate

---

2. Le Point Faible Architectural : L'Héritage Mémoire via fork()

Sous Linux, l'ASLR génère une base d'adresses aléatoire lorsqu'un nouveau programme est chargé via l'appel système execve().

Cependant, les serveurs web haute performance qui s'appuient sur PHP-FPM (FastCGI Process Manager) utilisent un modèle de processus pré-engendrés (Pre-forked Process Model) :

 [ Processus Maître PHP-FPM ] (Lancé au démarrage sous UID 0)
         │
         │── L'ASLR détermine la base mémoire des bibliothèques (ex: 0x7fff80000000)
         │
         ├── fork() ──> [ Travailleur 1 (PID: 2101) ] (Même carte mémoire physique)
         ├── fork() ──> [ Travailleur 2 (PID: 2102) ] (Même carte mémoire physique)
         └── fork() ──> [ Travailleur 3 (PID: 2103) ] (Même carte mémoire physique)

Selon la norme POSIX et l'implémentation du noyau Linux, l'appel système fork() duplique la table des pages du processus parent selon le mécanisme de Copie sur Écriture (Copy-on-Write).

Les conséquences pour la sécurité sont majeures :

1. Tous les processus travailleurs de PHP-FPM partagent exactement le même espace d'adressage virtuel et les mêmes bases de bibliothèques que le processus maître.
2. Si un attaquant envoie une requête avec un décalage d'adresse erroné et que le travailleur plante avec une erreur de segmentation (SIGSEGV), le processus maître ne s'interrompt pas.
3. Le processus maître réagit en engendrant instantanément un nouveau travailleur de remplacement via un nouvel appel fork().
4. Le nouveau travailleur reçoit rigoureusement la même disposition mémoire que celui qui vient d'être détruit.

Ce fonctionnement permet aux attaquants d'utiliser des bases d'adresses statiques déduites des images publiques Docker ou de tenter des décalages progressifs sans réinitialisation de l'ASLR entre les requêtes.

---

3. Le Risque Majeur des Binaires Compilés sans PIE

Le danger maximal se présente sur les serveurs où PHP a été compilé manuellement sans inclure les drapeaux de compilation -fPIE -pie.

Dans un binaire compilé en mode No PIE :

• La section de code exécutable (.text) est chargée à une adresse mémoire fixe et constante (habituellement 0x00400000 sous Linux x86_64).
• La fonction interne zif_system est localisée à un emplacement immuable visible avec readelf -s /usr/sbin/php-fpm.

Dans cette configuration, l'attaquant n'a même pas besoin de calculer l'adresse de glibc. Il lui suffit d'inscrire l'adresse absolue de zif_system dans sa structure zval falsifiée pour que le shell soit obtenu dès le premier tir avec une fiabilité de 100%.

---

4. Spécificités d'Alpine Linux et de la Bibliothèque musl libc

Une observation capitale pour les environnements de microservices concerne Alpine Linux.

Contrairement aux distributions majeures qui s'appuient sur la bibliothèque standard GNU (glibc), Alpine Linux utilise nativement musl libc.

Cette distinction modifie profondément la surface d'attaque :

1. Architecture de l'Allocateur Système : L'allocateur malloc-ng de musl libc segmente la mémoire et dispose ses pages de garde (guard pages) de manière totalement divergente par rapport aux arènes de glibc.
2. Adresses de Liaison Dynamique : Les bibliothèques partagées sous musl sont agencées dans des plages d'adresses plus compactes, invalidant les scripts d'exploitation standards développés pour Debian ou Ubuntu.
3. Résistance Accrue : Bien que la faille logique Use-After-Free soit présente dans le code source de PHP si session.upload_progress.enabled est actif, la construction d'un faux objet fonctionnel sous musl requiert un exploit entièrement recalculé. Les conteneurs Alpine bénéficient donc d'une résilience empirique supérieure face aux vagues de sondes génériques.

---

5. Mesures de Durcissement du Système d'Exploitation

Pour immuniser votre infrastructure contre les abus du modèle fork() :

A. Limitation des Redémarrages d'Urgence dans PHP-FPM

Configurez PHP-FPM pour forcer le redémarrage du processus maître (provoquant une ré-aléatorisation complète de l'ASLR) en cas de crashs anormaux :

Dans /etc/php/8.3/fpm/php-fpm.conf :

emergency_restart_threshold = 5
emergency_restart_interval = 60s
process_control_timeout = 10s

B. Désactivation des Volcats de Mémoire (Core Dumps) et de Ptrace

echo "kernel.core_pattern=|/bin/false" | sudo tee /etc/sysctl.d/60-security-hardening.conf
echo "fs.suid_dumpable=0" | sudo tee -a /etc/sysctl.d/60-security-hardening.conf
echo "kernel.yama.ptrace_scope=2" | sudo tee -a /etc/sysctl.d/60-security-hardening.conf
sudo sysctl --system

C. Confinement par Filtre Seccomp-BPF

En interdisant l'appel système execve au niveau du service systemd de PHP-FPM, le noyau bloquera toute tentative d'exécution de commande, rendant vaine toute tentative de contournement d'ASLR.

---

6. Analyse Approfondie de la Table d'Offsets Globale (GOT) et Protection RELRO

L'interaction entre l'ASLR et les mécanismes de protection des liaisons de bibliothèques (RELRO - Relocation Read-Only) constitue une composante essentielle de la résistance du système face à PHP2Shell :

A. La Vulnérabilité de la Table GOT sous Partial RELRO

Dans les environnements compilés avec Partial RELRO, la table globale des décalages d'adresses (Global Offset Table - GOT) demeure accessible en écriture pendant toute la durée d'exécution du processus. Si un attaquant parvient à détourner une écriture mémoire arbitraire via la corruption de pointeur, il peut écraser directement l'entrée d'une fonction fréquemment appelée (comme strlen ou memcpy) pour la faire pointer vers system().

B. L'Imperméabilité Conférée par Full RELRO

Sous Full RELRO (standard par défaut sous Ubuntu et Debian modernes), l'éditeur de liens dynamique résout l'intégralité des symboles dès le chargement initial du programme et remappe la section GOT en lecture seule stricte via mprotect(). Cette barrière empêche tout écrasement direct de la GOT, contraignant les attaquants à manipuler exclusivement les tables de gestionnaires d'objets (zend_object_handlers) situées dans le tas, démontrant l'importance cruciale de maintenir des options de durcissement complètes sur tous les binaires compilés.