Sur un hôte Linux, vous trouvez un fichier accessible en écriture par tous, appartenant à root et portant le bit SUID. Quel est le risque et votre action ?

Un binaire SUID (Set User ID) s'exécute avec les privilèges de son propriétaire, et non de l'utilisateur qui l'a lancé. Lorsque le propriétaire est root, tout code que ce binaire exécute s'exécute en tant que root. C'est acceptable pour un petit ensemble d'outils système soigneusement audités. Cela devient catastrophique dès l'instant où le fichier est aussi accessible en écriture par tous.

Pourquoi il s'agit d'une élévation de privilèges

Si un fichier est -rwsrwxrwx root root, n'importe quel utilisateur local peut écraser son contenu. Un attaquant remplace simplement le binaire (ou, pour un script, le modifie) par une charge utile de son choix — un shell, une commande qui ajoute une clé SSH à ~/.ssh/authorized_keys, ou une connexion inverse. À la prochaine exécution avec le bit SUID, cette charge utile s'exécute en tant que root. L'attaquant est passé d'un shell non privilégié au contrôle total de root sans exploiter le moindre bug de corruption mémoire. C'est l'une des primitives d'élévation de privilèges locale les plus fiables sous Linux.

La bonne action

• Retirez le bit SUID (chmod u-s) sauf s'il est réellement nécessaire.
• Corrigez le propriétaire et les permissions afin que le fichier ne soit pas accessible en écriture pour le groupe ou les autres (chmod o-w,g-w).
• Enquêtez sur la cause racine. Un fichier SUID appartenant à root et accessible en écriture par tous n'apparaît que rarement par accident. Vérifiez l'intégrité des paquets, les changements récents, et si un attaquant l'a créé comme porte dérobée ou mécanisme de persistance. Traitez-le comme un possible indicateur de compromission, pas comme un simple défaut d'hygiène.

Pourquoi les distracteurs échouent

• « Aucun risque » est tout simplement faux — c'est une voie d'élévation classique et cela révèle une lacune dangereuse de jugement.
• Chiffrer le fichier ne l'empêche pas de s'exécuter en SUID-root, et un attaquant peut toujours le remplacer ; vous n'avez rien résolu.
• Le renommer laisse le même binaire SUID accessible en écriture sur le disque sous un nouveau nom, toujours exploitable pour l'élévation.

Ce que l'examinateur cherche à évaluer

Si vous comprenez réellement le fonctionnement du SUID, savez relier « accessible en écriture par tous + SUID-root » à l'exécution de code arbitraire en tant que root, et passez instinctivement de la correction du fichier à la question de son origine — le réflexe de réponse à incident qui distingue un ingénieur confirmé d'un débutant.