Que faire setresuid() et setresgid() faire ?
Afin de mieux comprendre cet exemple, nous devons nous pencher sur ces deux fonctions et les trois paramètres qu'elles prennent.
À partir de cette réponse (et de la page de manuel "credentials(7)") :
Sous Linux, chaque processus possède les identifiants d'utilisateur et de groupe suivants :
ID utilisateur réel et ID de groupe réel. Ces ID déterminent à qui appartient le processus. Pour résumer, c'est qui vous êtes .
ID utilisateur effectif et ID de groupe effectif. Ces ID sont utilisés par le noyau pour déterminer les autorisations dont disposera le processus lors de l'accès aux ressources partagées telles que les files d'attente de messages, la mémoire partagée et les sémaphores. Sur la plupart des systèmes UNIX, ces ID déterminent également les autorisations lors de l'accès aux fichiers. Cependant, Linux utilise les ID du système de fichiers pour cette tâche. Pour résumer, c'est ce que vous pouvez faire .
ID d'utilisateur d'ensemble enregistré et ID de groupe d'ensemble enregistré. Ces ID sont utilisés dans les programmes set-user-ID et set-group-ID pour enregistrer une copie des ID effectifs correspondants qui ont été définis lors de l'exécution du programme. Un programme set-user-ID peut assumer et supprimer des privilèges en basculant son ID utilisateur effectif dans les deux sens entre les valeurs de son ID utilisateur réel et set-user-ID enregistré. Pour résumer, c'est qui vous étiez avant .
De plus, il est important de comprendre le SetUID-Bit. Ce que cela fait, c'est qu'il exécute un programme exécutable avec les droits du propriétaire, pas celui qui l'appelle.
Une sécurité nightmare
Votre question mentionne spécifiquement que nightmare appartient à root et a le jeu SetUID-Bit. Cela signifie que tout utilisateur autorisé à exécuter nightmare l'exécute essentiellement comme root . Cela signifie que tous les processus enfants de nightmare - tels qu'ils sont générés lors de l'appel de system() - sont également exécutés en tant que root .
Mais vraiment maintenant, qu'est-ce que setresuid() faire ?
Dans ce contexte? Rien. Puisque l'utilisateur exécute déjà des choses en tant que root , cela n'affecte en rien l'exploitation ultérieure.
Pourriez-vous utiliser /dev/tty ?
Cette question n'a pas beaucoup de sens dans ce contexte. Vous devez regarder l'extrait de code correspondant pour voir où se trouve la chaîne /dev/tty vient.
if (open("/dev/tty", O_RDWR) != -1) {
fire();
rax = sub_4008d0();
}
Cela signifie que le programme essaie d'ouvrir /dev/tty pour la lecture et l'écriture et si cela réussit, appelle fire() .
En nommant une fonction bash /dev/tty() , vous n'obtenez pas les résultats souhaités, car open() nécessite un chemin vers un fichier comme premier paramètre. C'est complètement indépendant de bash et n'a aucun concept de fonctions bash.
Qu'en est-il de puts() ?
De même, cela n'a pas beaucoup de sens. strings n'est pas une magie et ne comprend pas le contexte. Tout ce qu'il fait est de rechercher des séries d'octets qui sont des caractères ASCII imprimables.
puts() est juste une fonction C qui génère une chaîne.
Qu'en est-il de /usr/bin/aafire ?
Bien que je n'aie pas essayé personnellement, il semble que pratiquement /usr/bin/aafire aurait pu être utilisé à la place de /usr/bin/sl -al . Si ce n'est pas correct, veuillez commenter et je modifierai cette partie.
Est-ce que cela fonctionnerait toujours si un chemin relatif était utilisé ?
Oui, en fait encore mieux ! system() appelle en interne sh -c , qui doit résoudre le $PATH variable pour trouver sl . Si la variable de chemin a été modifiée pour inclure . ou tout autre répertoire accessible en écriture par l'utilisateur avec une priorité supérieure à /usr/bin , alors je pourrais simplement créer un lien symbolique ./sl à /bin/bash .
Le type de binaire/ELF du fichier SUID racine est-il important ?
Oui, car le SetUID-Bit est ignoré sur les scripts shell. Il doit s'agir d'un exécutable natif.