Comme vous avez certainement dû le lire sur les divers sites d’actualité Mac, une faille de sécurité existe sur nos systèmes OS X actuels. La commande sudo, qui permet d’exécuter une commande en tant que root ou en tant qu’autre utilisateur, présente une faille de sécurité. L’objet de cet article est d’exposer le fonctionnement de la faille pour l’exploiter, et donc s’en défendre.
Commençons par exploiter de nous-mêmes la faille en question pour comprendre comment elle marche et ainsi s’en prémunir.
Le problème référencé sous le code CVE-2013-1775 (CVE pour Common Vulnerabilities and Exposures) indique que certaines versions de la commande sudo présentent un problème de gestion du temps et du cache d’authentification.
La chose est présentée comme telle : depuis un utilisateur disposant des droits d’utilisation de la commande sudo et ayant déjà utilisé cette commande, il est possible de devenir root sans mot de passe à condition de changer la date du système et la régler au 1er janvier 1970, l’epoch UNIX.
Pour mettre en œuvre cela, authentifiez sur votre Mac avec un compte administrateur puis assurez-vous d’avoir déjà fait un sudo -s. Fermez le terminal, laissez passer 5 min, réessayez de faire un sudo, le système vous redemande votre mot de passe. En deçà des 5 min, le système vous autorise à refaire un sudo sans entrer de nouveau votre mot de passe.
Maintenant que vous êtes certain d’avoir fait une fois un sudo dans votre vie, vous allez pouvoir essayer d’attaquer votre système.
Pour cela, commencez par faire un sudo -k, ensuite il vous faut vous rendre dans les préférences système du Mac puis dans la section « Date et heure » pour enfin désactiver l’utilisation des serveurs de temps et vous placer au 1er janvier 1970 à 1h.
Retournez dans votre terminal, faites un sudo -s, vous n’avez pas besoin de rentrer votre mot de passe pour passer root.
Cette action exploite un problème dans l’implémentation de la gestion du cache d’authentification de la commande lorsque la date du système est proche de l’origine du temps sous UNIX.
L’intéressant ici est de comprendre comment est géré le système de cache d’authentification de la commande. Chose expliquée dans sa documentation.
/var/db/sudo Directory containing time stamps
Effectivement, si l’on regarde dans le dossier en question, nous verrons qu’un dossier vide, au nom de l’utilisateur, est créé lors de la dernière utilisation de la commande sudo.
yoanngini@Yoann-Air ~ 20:22 % sudo ls -l /var/db/sudo
total 0
drwx------ 2 root wheel 68 29 aoû 20:22 yoanngini
La date de création du dossier sert tout simplement de timestamp d’authentification.
Si l’on supprime ce dossier, la commande sudo perd sa mémoire et vous redemande votre mot de passe.
Maintenant que vous savez comment fonctionne la commande et la faille, il est aisé de comprendre comment s’en prémunir le temps qu’Apple fournisse un correctif de sécurité.
Par exemple, vous pourriez ajouter deux services launchd. Le premier lancé au démarrage du système supprimera tout le contenu du dossier /var/db/sudo. Le second observera tout changement dans le dossier /var/db/sudo pour de nouveau tout supprimer.
Cela permettra deux choses :
- supprimer tout fichier créé avec le système à froid lors du démarrage ;
- supprimer les timestamp sudo dès leur création ;
Certes, cela imposera de taper votre mot de passe à chaque utilisation de sudo, mais cela devrait vous protéger. D’autres solutions sont également possibles.
Je laisse le choix de la solution et l’écriture des services au soin de chacun.
Bonjour,
est-ce qu’activer l’option « tty_tickets » (elle ne l’est pas par défaut) ne permettrait pas de régler le problème pour l’essentiel (sauf à vouloir se hacker soi-même bien sûr) ?
En l’activant, le ticket obtenu avec sudo est lié au TTY sur lequel on l’a obtenu : du moment qu’on a quitté ce shell, le mot de passe sera redemandé.
Mon idée derrière la proposition de launchd était de se baser sur quelque chose d’extérieur à sudo et pas facilement trouvable.
En plus simple on peut aussi régler timestamp_timeout à 0 pour qu’il demande toujours le mot de passe.
Concernant l’option tty_tickets, c’est peu fiable je dirais car les tty n’ont pas des noms aléatoire, ils sont toujours réutilisé. De fait on peut très bien se retrouver avec le même problème.
Bien vu :-)
Un $ sudo visudo
Puis on ajoute dans # Defaults specification, la ligne :
Defaults timestamp_timeout=0
C’est effectivement ce que je proposais dans le commentaire précédent.
Cependant cela se repose toujours sur le mécanisme interne de sudo en terme de sécurité.
L’idée que j’ai eu en proposant le système de launchd était d’avoir un système externe pour s’assurer que sudo travail correctement, peut importe la manière qu’il aura d’interpréter ses réglages.