CVE-2022-37706-LPE-exploit

CVE-2022-37706

Salut les gars, cette fois je vais parler d'un 0-day récent que j'ai trouvé dans l'un des
principaux gestionnaires de fenêtres de Linux, appelé Enlightenment (https://www.enlightenment.org/).
Ce 0-day permet à n'importe quel utilisateur d'obtenir les privilèges root très facilement et instantanément.
L'exploit est testé sur Ubuntu 22.04, mais devrait fonctionner sans problème sur n'importe quelle distribution.

Tout d'abord, Enlightenment est un gestionnaire de fenêtres, un compositeur et un bureau minimal
pour Linux (la plateforme principale), BSD et tout autre système UNIX compatible.

J'ai installé ce gestionnaire de fenêtres pour expérimenter un peu avec. C'était intéressant
pour moi car il contient beaucoup d'outils et il est plutôt sympa, honnêtement.

Après avoir installé le paquet avec apt install enlightenment, j'ai examiné les
fichiers et répertoires installés sur mon système, beaucoup de modules et de binaires
d'aide, mais ce qui est le plus intéressant est :

➜  enlightenment cd /usr/lib/x86_64-linux-gnu/enlightenment/
➜  enlightenment find . -perm -4000                         
./utils/enlightenment_ckpasswd
./utils/enlightenment_system
./utils/enlightenment_sys

Il installe des binaires SUID, puis je me suis demandé si je pouvais utiliser l'un d'eux
pour élever les privilèges jusqu'à root ; les binaires semblaient tous sécurisés et bien codés.
Le binaire dont nous allons parler est enlightenment_sys.

Comme pour toute autre cible, nous choisissons une stratégie à appliquer après une pré-évaluation,
voyez mon blog ici si ce n'est pas déjà fait (https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html)

J'ai audité le code avec une approche descendante (Top-Down).
Et comme ce gestionnaire de fenêtres est open source, le code source est disponible
pour tous ces binaires et modules.
La première chose que j'ai faite a donc été apt source enlightenment pour obtenir tout le code source,
et avec un peu de recherche, on peut arriver au code du binaire cible.

Mais pour déboguer le binaire, je l'ai chargé dans Ghidra pour l'analyser et avoir des adresses
pour poser des points d'arrêt, etc.
Aucun symbole n'a été trouvé au premier essai, mais bon, pas besoin de ceux-ci car il s'est avéré
être un binaire relativement petit.
Étonnamment, j'ai trouvé très agréable de regarder le pseudo-code décompilé de
Ghidra plutôt que de regarder directement le source (évite les macros, évite aussi les vérifications
liées à l'OS utilisé pour compiler un bloc de code spécifique).

Commençons donc l'analyse.

1- Jouons avec le binaire.
Lançons le fichier pour voir quelques informations sur notre cible :

Lancer le binaire ne donne aucune sortie :

Donner l'argument --help affiche ceci :

Désolé, je vais l'utiliser pour devenir root.

Ensuite, utilisons simplement strace pour voir s'il utilise des appels système suspects comme
execve ou openat :
strace ./enlightenment_sys 2>&1 | grep open

Il ouvre seulement des bibliothèques connues à des endroits où nous n'avons pas la permission de modifier quoi que ce soit.

strace ./enlightenment_sys 2>&1 | grep exec

2- Faisons de la rétro-ingénierie sur le binaire, puis exploitons-le.

J'ai créé un nouveau projet Ghidra et j'ai chargé ce binaire spécifique.
Comme les symboles n'ont pas été trouvés, on peut repérer la fonction main en utilisant entry.
Le premier argument de la fonction entry est main lui-même.
Je l'ai renommée main pour de futures références.
En défilant un peu, je peux déjà repérer l'utilisation de la fonction system().

En tant que pwner, je passe des jours sur des challenges à faire apparaître cette fonction précise x)
J'ai rétro-ingénié le binaire à la recherche d'un bug de corruption mémoire ou de problèmes de heap
, mais en réalité c'était une injection de commande étrange.
Le binaire prend toutes les précautions de sécurité avant d'exécuter system, mais malheureusement,
on peut toujours y injecter notre entrée.

OK, maintenant parcourons le binaire du début jusqu'à notre fonction system, en essayant d'y
injecter notre entrée.

D'abord, le binaire vérifie simplement si le premier argument est --help ou -h et affiche ce
message que nous avons vu plus tôt.

Ensuite, il élève ses privilèges à root.

Puis il désactive presque toutes les variables d'environnement (précautions de sécurité) pour ne pas
invoquer un autre binaire non prévu.

Donc si le premier argument que nous avons entré est "mount", il entre dans cette branche, vérifie certains
drapeaux fournis, et ces drapeaux vont être placés sur la pile.

Ensuite, il vérifie si le paramètre suivant après mount est UUID= ; nous ne voulons pas entrer
ici, donc nous avons fourni "/dev/../tmp/;/tmp/exploit".

Ainsi, nous passons la vérification à la ligne 410, celle du strncmp.
Car s'il ne commence pas par /dev/, le binaire se termine.
Ensuite, il y a un appel à stat64 sur ce fichier que nous avons fourni ; notez que nous pouvons
créer un dossier appelé ";" et cela provoquera l'injection de commande.
Jusqu'à présent, l'exploit a déjà créé ce fichier /dev/../tmp/;/tmp/exploit,
mais ce n'est pas l'exploit qui sera appelé.

Nous nous rapprochons maintenant de system().
À présent, p (le pointeur) est mis à jour avec le dernier argument donné à notre binaire SUID,
/tmp///net.

Pourquoi fournir /tmp///net alors qu'on peut passer /tmp/net ?
Nous allons contourner cette vérification :
if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))
Nous avions besoin que /tmp/net existe et que /tmp/// ait une longueur de 6.

Maintenant, le dernier stat64 va vérifier l'existence de "/dev/net"
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);
Et il le trouvera, donc nous passons cette dernière vérification.

Maintenant, il va vérifier la disponibilité de certains fichiers, mais ce n'est pas important
à ce stade, car tout est prêt et nous sommes tout proches de déclencher une exécution
arbitraire de commandes.

Maintenant, eina_strbuf_new() va simplement initialiser la commande qui sera passée à
system ; le problème ici est que nous l'avons entrée comme :

/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net

Mais le binaire appelle eina_strbuf_append_printf() plusieurs fois et la commande devient
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net
Remarquez que les guillemets doubles sont supprimés, et nous pourrons appeler /tmp/exploit
en tant que root.

Le binaire a fait de son mieux pour atténuer tout comportement non prévu, mais comme toujours,
tout peut être pwné. Je ne m'attendais pas à exploiter cela avec un bug logique
de ce type.
Je veux que la prochaine CVE soit une corruption mémoire menant à une élévation de privilèges locale (LPE) vers root.

Divulgation sur Twitter : https://twitter.com/maherazz2/status/1569665311707734023