PATH hijacking : comprendre et prévenir l’escalade de privilèges

Le principe

Pour une commande donnée sans chemin (ls), le système parcourt dans l’ordre les dossiers listés dans PATH et lance le premier exécutable trouvé. Si un dossier contrôlé par l’attaquant passe avant /bin, son ls est lancé à la place du vrai.

Un code vulnérable

Un programme exécuté avec des droits élevés (SUID, tâche planifiée, commande autorisée par sudo) qui lance une commande par son nom :

#include <stdlib.h>

int main(void) {
    system("ls /var/log");   /* "ls" est cherché dans $PATH */
    return 0;
}

Si l’environnement de l’appelant est conservé, rien ne garantit que ls désigne /bin/ls.

Détecter ce risque lors d’un audit

• Repérer les commandes lancées sans chemin absolu, avec strings sur le binaire ou ltrace et strace à l’exécution.
• Vérifier que les dossiers de PATH ne sont pas modifiables par des utilisateurs non privilégiés.
• Lire sudo -l : une règle qui conserve PATH (env_keep) est un signal d’alerte.
• Lister les binaires SUID avec find / -perm -4000 -type f 2>/dev/null et les examiner.

Corriger

Un chemin absolu et un environnement minimal maîtrisé :

#include <unistd.h>

int main(void) {
    char *const env[] = { "PATH=/usr/bin:/bin", NULL };
    execle("/bin/ls", "ls", "/var/log", (char *)NULL, env);
    return 1;   /* atteint seulement si exec échoue */
}

• Toujours des chemins absolus dans le code privilégié, et éviter system() et popen() avec des chaînes interprétées par un shell.
• Avec sudo, garder env_reset et secure_path, qui sont les réglages par défaut de Debian.
• Ne jamais mettre . ou un dossier modifiable par les utilisateurs dans le PATH d’un compte privilégié.
• Appliquer le principe de least privilege : abandonner les droits dès qu’ils ne sont plus nécessaires, monter les partitions de données avec nosuid.

Pourquoi c’est un classique

Ce scénario revient dans de nombreux challenges d’escalade de privilèges. Le comprendre côté défense est précisément ce qui permet d’écrire du code et des configurations qui n’y sont pas vulnérables.

Sources

• CWE-426 : Untrusted Search Path
• sudoers : env_reset et secure_path