Pourquoi le bit setuid fonctionne-t-il de manière incohérente?

J'ai écrit le code:

// a.c
#include <stdlib.h>
int main () {
  system("/bin/sh");
  return 0;
}

compilé avec la commande:

gcc a.c -o a.out

ajouté un bit setuid dessus:

sudo chown root.root a.out
sudo chmod 4755 a.out

Sur Ubuntu 14.04, lorsque je cours en tant qu'utilisateur général, j'ai obtenu le privilège root.

mais sur Ubuntu 16.04, j'ai toujours le shell de l'utilisateur actuel.

Pourquoi est-ce différent?

Ce qui a changé, c'est que /bin/shsoit est devenu, soit est bashresté, dashce qui a obtenu un drapeau supplémentaire -pimitant le comportement de bash.

Bash nécessite que le -pdrapeau ne supprime pas le privilège setuid comme expliqué dans sa page de manuel :

Si le shell est démarré avec l'ID utilisateur (groupe) effectif différent de l'ID utilisateur (groupe) réel et que l'option -p n'est pas fournie, aucun fichier de démarrage n'est lu, les fonctions shell ne sont pas héritées de l'environnement, le SHELLOPTS , Les variables BASHOPTS, CDPATH et GLOBIGNORE, si elles apparaissent dans l'environnement, sont ignorées et l'ID utilisateur effectif est défini sur l'ID utilisateur réel . Si l'option -p est fournie lors de l'appel, le comportement de démarrage est le même, mais l'ID utilisateur effectif n'est pas réinitialisé.

Avant, dashne se souciait pas de cela et permettait l'exécution de setuid (en ne faisant rien pour l'empêcher). Mais la dashpage de manuel d'Ubuntu 16.04 a une option supplémentaire décrite, similaire à bash:

-p priv
N'essayez pas de réinitialiser l'uid effectif s'il ne correspond pas à l'uid. Ce paramètre n'est pas défini par défaut pour éviter une utilisation incorrecte par les programmes racine setuid via le système (3) ou popen (3).

Cette option n'existait pas en amont (qui pourrait ne pas avoir été réactif à un correctif proposé ^* ) ni Debian 9 mais est présente dans Debian buster qui a obtenu le correctif depuis 2018.

NOTE: comme l' explique Stéphane Chazelas, il est trop tard pour invoquer "/bin/sh -p"en system()raison system()runs quoi que ce soit donné par /bin/shet donc le setuid est déjà tombé. La réponse de Derobert explique comment gérer cela, dans le code précédent system().

^* plus de détails sur l'histoire ici et là .

Le shell est probablement en train de remplacer son ID utilisateur effectif par l'ID utilisateur réel dans le cadre de son démarrage pour une raison ou une autre. Vous pouvez le vérifier en ajoutant:

/* needs _GNU_SOURCE; non-Linux users see setregid/setreuid instead */
uid_t euid = geteuid(), egid = getegid();
setresgid(egid, egid, egid);
setresuid(euid, euid, euid);

avant votre system(). (En fait, même sous Linux, vous n'avez probablement besoin que de définir les vrais; ceux enregistrés devraient être bien de laisser seuls. C'est juste une force brute pour déboguer. Selon la raison pour laquelle vous êtes set-id, vous devrez bien sûr avoir besoin pour enregistrer également les vrais identifiants.)

[De plus, si ce n'est pas seulement un exercice pour apprendre comment fonctionne setid, alors il y a beaucoup de problèmes de sécurité à se soucier, en particulier lors de l'appel d'un shell. Il existe de nombreuses variables d'environnement, par exemple, qui affectent le comportement du shell. Préférez une approche déjà existante comme sudosi possible.]