• Se trouve sur la même machine hôte / WSL
• Utilise Python3 + paramiko pour exécuter le PoC, construisant un identifiant client SSH spécifique et initiant une poignée de main pré-authentification

Structure du répertoire :

• Dockerfile : Image pour construire l'environnement vulnérable OpenSSH 9.1p1
• poc.py : Client PoC minimal pour déclencher le double free en phase de pré-authentification

Prérequis

Avant d'effectuer les opérations suivantes dans ce répertoire, assurez-vous :

• Docker est installé (sous WSL2, il est recommandé d'utiliser Docker Desktop ou d'installer Docker directement dans WSL)
• Python 3 et pip sont installés

1. Construction de la cible (OpenSSH 9.1p1 dans Docker)

1. Construire l'image

Exécutez dans ce répertoire :

2. Démarrer le conteneur

Explication :

• --rm : Supprime automatiquement le conteneur après sa sortie
• --name sshd-vuln : Nom du conteneur
• -p 2222:22 : Mappe le port 22 interne du conteneur sur le port 2222 de l'hôte

3. Vérifier l'état de sshd

Vous devriez voir quelque chose comme :

2. Utilisation du PoC de l'attaquant

1. Installer les dépendances PoC

Exécutez dans ce répertoire :

2. Description du script PoC (poc.py)

poc.py utilise paramiko.Transport pour établir activement une connexion avec le serveur SSH cible, contrefait l'identifiant client en phase de pré-authentification et tente de déclencher le double free.

Caractéristiques clés :

• Cible par défaut : 127.0.0.1:2222 (c'est-à-dire le conteneur Docker local)
• Identifiant client par défaut : SSH-2.0-PuTTY_Release_0.64
• Fournit des paramètres simples en ligne de commande :
  • -t/--target : IP cible (par défaut 127.0.0.1)
  • -p/--port : Port cible (par défaut 2222)
  • -c/--client-id : Identifiant SSH client contrefait
  • --timeout : Délai d'attente (secondes)
  • -v/--verbose : Affiche les informations d'erreur détaillées

3. Exécuter le PoC

Assurez-vous que le conteneur sshd-vuln est démarré, puis exécutez dans ce répertoire :

Ou spécifiez explicitement les paramètres :

Exemple de sortie attendue du client :

Explication :

• Du côté client, l'erreur Authentication failed ou connection closed est attendue, car le sous-processus de pré-authentification du serveur peut planter ou fermer activement la connexion pendant le traitement.

3. Résultats attendus et méthode de vérification

1. Logs du serveur (conteneur)

Après avoir exécuté le PoC, consultez les logs du conteneur sur l'hôte :

Vous devriez voir une sortie similaire :

Où :

• Invalid user : En raison de l'utilisation d'un nom d'utilisateur vide par le PoC, OpenSSH enregistre une tentative d'utilisateur invalide
• free(): double free detected in tcache 2 : glibc détecte un double free et termine le sous-processus sshd en cours ; c'est le phénomène de corruption mémoire / DoS que cette expérience vise à observer

Remarque : Pour pouvoir voir cette ligne, nous avons désactivé le bac à sable seccomp lors de la construction d'OpenSSH (--with-sandbox=no). Sinon, le bac à sable pourrait intercepter le comportement anormal avant le double free et terminer directement le sous-processus.

2. Nature de l'effet

• Dans cet environnement expérimental, le PoC déclenche de manière fiable un crash du sous-processus de pré-authentification (DoS), entraînant l'échec de la connexion SSH en cours. Le processus principal sshd continue de créer de nouveaux sous-processus pour les connexions ultérieures.
• Étant donné que le sous-processus de pré-authentification s'exécute dans un environnement à privilèges réduits + chroot et que plusieurs mécanismes de sécurité sont activés par défaut, les chercheurs considèrent généralement qu'il est extrêmement difficile de se fier uniquement à ce double free pour une exécution de code à distance.