sideeffect42/rootpipetesterRootPipe (CVE-2015-1130) et Phoenix (CVE-2015-3673), utilitaire de test de vulnérabilités pour Mac OS X 10.2.8 et versions ultérieures
RootPipe Tester est une petite application qui s'exécute sur votre Mac (Mac OS X 10.2.8 ou supérieur, sur PowerPC et Intel) et tente d'utiliser à la fois les exploits RootPipe (CVE-2015-1130) et Phoenix (CVE-2015-3673) pour produire une élévation de privilèges.
La vulnérabilité de votre Mac dépend de la version de Mac OS X que vous utilisez, mais sa réussite dépend aussi des préférences que vous avez définies.
Avec RootPipe Tester, j'ai créé une solution en un clic pour vous permettre de vérifier si vous êtes vulnérable sans avoir à effectuer de nombreux essais et tests.
Téléchargez l'image disque depuis la page des versions de ce dépôt ou compilez-la vous-même si vous préférez.
Montez l'image disque et exécutez l'application qu'elle contient (il est sûr d'exécuter RootPipe Tester depuis l'image disque).
Cliquez sur "Démarrer le test" et laissez le test s'exécuter (vous pouvez savoir s'il est terminé grâce à "En cours…" dans le titre de la fenêtre).
Pour obtenir des résultats précis, je vous recommande de redémarrer votre Mac et de relancer le test après une « nouvelle connexion ».
Si au moins l'un des essais a détecté un système vulnérable, vous voudrez peut-être consulter la section PANIQUE.
Non ! Restez calme et lisez le guide adapté à votre version du système.
Remarque : « Non vulnérable » en autorisation utilisateur signifie que le système n'accordera pas l'accès ou affichera une boîte de dialogue d'autorisation vous demandant de vous authentifier en tant qu'utilisateur administrateur.
Dans une certaine mesure, c'est aussi une élévation de privilèges, car le groupe admin n'a pas autant de droits que root, mais dans la configuration par défaut de sudo, tout utilisateur du groupe « admin » peut obtenir root en saisissant son mot de passe ; le même effet peut donc également être obtenu en exécutant simplement sudo.
Mettez à niveau vers 10.10.3 dès que possible pour vous assurer que le système applique correctement les entitlements sur le binaire writeconfig. (du moins, c'est ce que dit Apple)
Si, pour une raison quelconque, vous ne pouvez pas mettre à niveau vers 10.10.3, consultez la section concernant OS X 10.9 Mavericks.
Mavericks permet à un attaquant de passer avec une autorisation nil, ce qui vous place dans une situation bien plus difficile qu'avec les anciennes versions de Mac OS X.
Vous voudrez peut-être jeter un œil à can_I_suid.
Résultats des tests :
Vulnérable
Vous devriez activer « Exiger un mot de passe pour déverrouiller chaque volet des préférences Système » dans le volet Sécurité des préférences Système.
Résultats des tests :
Non vulnérable
Félicitations ! Vous possédez l'une des versions les plus sécurisées de Mac OS X (du moins en ce qui concerne RootPipe).
Sur ces systèmes, l'option « Exiger un mot de passe pour déverrouiller chaque volet des préférences Système » (« Exiger un mot de passe pour déverrouiller chaque préférence système sécurisée » dans Tiger) du volet Sécurité fonctionne correctement et devrait vraiment être activée !
Remarque : Si la case « Exiger un mot de passe » n'est pas cochée, le système déverrouillera les volets de préférences sécurisés à chaque connexion. Si vous utilisez un compte administrateur, cela rendra votre système vulnérable jusqu'à ce que vous ayez refermé manuellement le cadenas dans les Préférences Système après chaque connexion.
Résultats des tests :
Non vulnérable
Contrairement aux systèmes plus récents, sous Panther, la case « Exiger un mot de passe pour déverrouiller chaque préférence système sécurisée » du volet Sécurité ne suffit pas à empêcher complètement le fonctionnement de cet exploit. Je recommande tout de même de la cocher.
Pour sécuriser votre système, je vous recommande fortement de n'utiliser qu'un compte d'utilisateur standard et de toujours « fermer le cadenas » manuellement après avoir modifié des préférences dans les Préférences Système.
Le simple fait de fermer les Préférences Système n'invalidera pas correctement l'autorisation et cet exploit fonctionnera jusqu'à votre déconnexion, même si l'interface des Préférences Système affiche un cadenas fermé lorsque vous êtes un utilisateur standard.
Résultats des tests :
Non vulnérable
Contrairement aux systèmes plus récents, Jaguar ne fournit pas de case « Exiger un mot de passe pour déverrouiller chaque préférence système sécurisée », mais il déverrouille tout de même les volets de préférences sécurisés à la connexion pour tous les utilisateurs administrateurs.
Pour sécuriser votre système, je vous recommande fortement de passer à l'utilisation d'un compte d'utilisateur standard uniquement.
Remarque : Jaguar ne verrouille pas les volets de préférences sécurisés lorsque les Préférences Système se ferment, alors verrouillez toujours les volets sécurisés manuellement. Si vous ne le faites pas, l'exploit fonctionnera jusqu'à votre déconnexion.
Remarque : Si vous ne pouvez pas passer à un compte d'utilisateur standard, un simple AppleScript qui verrouille les volets de préférences sécurisés en tant qu'élément de connexion pourrait faire l'affaire.
Remarque : La version normale de RootPipe Tester ne fonctionnera pas sous Jaguar. Téléchargez la version Legacy de RootPipe Tester si vous souhaitez l'utiliser sous Jaguar.
La version Legacy de RootPipe Tester est équivalente en termes de fonctionnalités à la version normale, mais elle est compilée avec GCC 3.1 au lieu de GCC 4.0.
Résultats des tests :
Non vulnérable
Un exploit pour Puma semble réalisable, car il utilise les mêmes étapes pour authentifier les Préférences Système et la plupart des composants nécessaires sont présents.
La seule chose qui entrave un exploit est que Puma ne dispose pas de SecurityFoundation.framework, utilisé dans les versions ultérieures pour autoriser.
À la place, il utilise un framework privé nommé NIInterface.framework qui doit d'abord faire l'objet d'une rétro-ingénierie.
Bonne nouvelle quand même : personne ne va investir du temps pour exploiter une base d'utilisateurs probablement quasi inexistante.
Pour renforcer la sécurité, il est toujours recommandé de n'utiliser qu'un compte d'utilisateur standard et de verrouiller manuellement les volets de préférences sécurisés.
Remarque : Prenez ce paragraphe avec des pincettes. J'ai fait de mon mieux pour comprendre ce qui se passe réellement, mais comme tout repose sur des frameworks privés, on ne peut jamais savoir à 100 % ce que ces méthodes font, surtout sur autant de versions de Mac OS X que j'essaie de couvrir.
Le fonctionnement de l'exploit RootPipe est fondamentalement le même que celui des Préférences Système pour écrire les fichiers de configuration (d'où le nom WriteConfig), à la différence que les utilisateurs de cet exploit ne doivent pas être l'application Préférences Système.
Jusqu'ici, ce n'est pas si horrible, et en fait, tout l'exploit n'est pas si horrible non plus.
Mais regardons le code.
// Authorization
SFAuthorization auth = [SFAuthorization authorization];
id authenticator = [Authenticator sharedAuthenticator];
[authenticator authenticateUsingAuthorizationSync:auth];
// Profit?
id sharedLiaison = [ToolLiaison sharedToolLiaison];
id tool = [sharedLiaison tool];
Comme vous pouvez le voir, c'est du code « à l'ancienne », mais le principe pour le nouveau style est plus ou moins le même.
Les trois premières lignes de cet extrait concernent l'autorisation et les deux dernières sont le vrai morceau intéressant.
Si un volet de préférences dans les Préférences Système doit effectuer des opérations nécessitant des privilèges, il place un SFAuthorizationView (le symbole du cadenas) dans le coin inférieur gauche. Ce SFAuthorizationView gère ensuite l'acquisition et la destruction du droit system.preferences.
Jusqu'ici, tout va bien, mais qu'est-ce que ce system.preferences ?
Les droits qu'Apple utilise et leur configuration ont changé au fil du temps, mais le principe est resté le même. Vous trouverez ci-dessous un extrait de la base de données de politiques des services d'autorisation.
system.preferences sur 10.5.8
{
"allow-root" = 1;
class = user;
comment = "Checked by the Admin framework when making changes to certain System Preferences.";
group = admin;
shared = 1;
}
Comme vous pouvez le voir, il s'agit d'un droit partagé. Cela signifie qu'une fois ce droit acquis par un processus, tout autre processus peut l'utiliser tant que la session n'est pas détruite (à la déconnexion).
En soi, ce n'est pas si grave, car vous devez autoriser la première fois qu'une application veut utiliser system.preferences ; malheureusement, le système l'autorise automatiquement à la connexion (pour les utilisateurs administrateurs).
Cela signifie que notre RootPipe Tester n'aura pas à être autorisé et pourra utiliser l'autorisation du système.
Les utilisateurs standard sont en sécurité, car le système n'autorise pas le droit system.preferences à la connexion.
Une fois la bonne autorisation acquise, écrire des fichiers de configuration (ou n'importe quel autre fichier d'ailleurs) avec des droits arbitraires devient un jeu d'enfant.
ToolLiaison va volontiers configurer un NSDistantObject vers writeconfig pour vous, et writeconfig écrira volontiers le fichier pour vous, car, à ses yeux, vous vous êtes parfaitement autorisé.
Cocher la case « Exiger un mot de passe pour déverrouiller chaque volet des préférences Système » dans les Préférences Système corrige RootPipe sur toutes les versions de Mac OS X de 10.4 à 10.8.
Cocher cette case modifie le droit system.preferences et définit shared sur false.
Si un droit n'est pas partagé, cela signifie que chaque processus doit obtenir sa propre autorisation. Comme l'obtention d'une autorisation exige que l'utilisateur saisisse le mot de passe d'un administrateur, l'attaque peut être remarquée par l'utilisateur.
De plus, le simple fait d'exécuter sudo aura le même effet, ce qui rend cette attaque inutile.
Pas vraiment. À première vue, cela pourrait en ressembler une, car c'est un framework privé fonctionnant en root et ne faisant pas une authentification correcte.
Mais le vrai problème ici relève davantage d'une mauvaise conception. Apple voulait s'assurer que chaque utilisateur administrateur ait la possibilité d'utiliser pleinement les Préférences Système, et sous Unix tout a besoin d'un fichier de configuration, et ces fichiers doivent être écrits (la plupart du temps en root).
On pourrait dire que c'est une mauvaise idée (je serais d'accord), mais je ne considérerais pas cela comme une porte dérobée, car l'authentification fonctionne correctement et tout administrateur a de toute façon la possibilité d'obtenir root via sudo.
Le principal problème ici est qu'Apple a privilégié le confort à la sécurité, mais ce n'est pas non plus quelque chose de très exceptionnel de leur part.