Microsoft signale une vulnérabilité «Shrootless» contournant SIP dans macOS

| |

Agrandir / Le ver dit : “J’ai la racine !”

Andreus / Getty Images

L’équipe de recherche Microsoft 365 Defender a publié un article de blog hier décrivant une vulnérabilité macOS récemment découverte qui peut abuser de l’héritage des droits dans la protection de l’intégrité du système (SIP) de macOS pour permettre l’exécution de code arbitraire avec des privilèges de niveau racine. La vulnérabilité est répertoriée comme CVE-2021-30892 et a reçu le surnom de “Shrootless”.

Pour expliquer le fonctionnement de Shrootless, nous devons revoir le fonctionnement de SIP. Introduit en 2015 avec OS X 10.11 El Capitan (et expliqué en détail sur pages huit et neuf de notre revue), SIP tente de supprimer toute une classe de vulnérabilités (ou au moins de neutraliser leur efficacité) en ajoutant des protections au niveau du noyau contre la modification de certains fichiers sur le disque et de certains processus en mémoire, même avec le privilège root. Ces protections sont (plus ou moins) inviolables sauf si l’on désactive SIP, ce qui ne peut se faire sans redémarrer en mode recovery et exécuter une commande de terminal.

L’exploit Shrootless tire parti du fait que, bien que le privilège root ne soit plus suffisant pour modifier des fichiers système importants, le noyau lui-même peut toujours modifier les emplacements protégés selon les besoins. L’exemple le plus évident est l’installation d’une application. Les packages d’installation d’applications signés par Apple ont la capacité de faire des choses normalement interdites par SIP, et c’est là qu’intervient Shrootless.

Conséquences inattendues

Comme expliqué par Jonathan Bar Or, chercheur senior en sécurité chez Microsoft, dans un blog Publier, SIP doit être en mesure d’accorder temporairement l’immunité aux packages d’installation de SIP afin d’installer des éléments, et il le fait en transmettant cette immunité temporaire via un système d’héritage intégré :

En évaluant les processus macOS autorisés à contourner les protections SIP, nous sommes tombés sur le démon system_installd, qui a le puissant com.apple.rootless.install.inheritable droit. Avec ce droit, tout processus enfant de system_installd serait capable de contourner complètement les restrictions du système de fichiers SIP.

Cela en soi n’est pas trop terrifiant, car un jour normal, il ne devrait pas y avoir quoi que ce soit d’effrayant hors du system_installd démon. Cependant, comme le note la publication d’Or, certains packages d’installation contiennent des scripts de post-installation, et macOS exécute ces scripts de post-installation en créant une instance du shell système par défaut, qui, à partir de Catalina, est zsh. Lorsqu’une instance zsh est générée par le programme d’installation, elle exécute automatiquement son fichier de démarrage à /etc/zshenv-et c’est le problème, car si un attaquant a déjà modifié ce fichier, quelles que soient les modifications apportées par l’attaquant sont exécutées par zsh avec le com.apple.rootless.install.inheritable droit.

Ou résume les choses ainsi :

Généralement, zshenv pourrait être utilisé comme suit :

  • Un mécanisme de persistance. Il pourrait simplement attendre zsh pour commencer (soit globalement sous /etc ou par utilisateur).
  • Un mécanisme d’élévation des privilèges. Le répertoire personnel ne change pas lorsqu’un utilisateur administrateur passe à la racine en utilisant sudo -s ou sudo . Ainsi, placer un ~/.zshenv fichier en tant qu’administrateur et en attendant que l’administrateur utilise sudo déclencherait plus tard le ~/.zshenv fichier, s’élevant ainsi à la racine.

Par le CVE, la vulnérabilité a déjà été corrigée dans les trois versions actuellement prises en charge de macOS (Monterey 12.0.1, Catalina avec la mise à jour de sécurité 2021-007 et Big Sur 11.6.1). Les anciennes versions non prises en charge d’OS X avec SIP, ce qui signifie OS X 10.11 et versions ultérieures, peuvent toujours être vulnérables, bien que cela dépende probablement du fait que les scripts de post-installation exécutés avec bash se comportent de la même manière qu’avec zsh.

L’article de blog d’Or ne mentionne pas si Apple a payé à Microsoft un prime de bogue.

Previous

L’Australie en tête de liste des nations prêtes à profiter du boom de l’hydrogène

Tom Hanks se promène dans les photos de mariage sans y être invité

Next

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.