PwnKit, ou comment un code vieux de 12 ans peut donner accès à la racine à des utilisateurs non privilégiés

Il semble que les équipes informatiques n'aient pas de répit. Après tous les ennuis causés par log4j (et ses variantes), une nouvelle vulnérabilité très médiatisée et à haut risque fait son apparition. CVE-2021-4034, ou PwnKit si vous aimez les surnoms fantaisistes de CVE, est une vulnérabilité de polkit qui permet aux utilisateurs non privilégiés d'obtenir les privilèges root sur pratiquement tous les systèmes Linux sur lesquels polkit est installé.

L'équipe de support du cycle de vie étendu de TuxCare prépare des correctifs pour toutes les distributions supportées, et ils seront bientôt disponibles pour le déploiement. Ce post sera mis à jour pour refléter la disponibilité réelle pour chaque distribution au fur et à mesure.

[NOTE : Des correctifs sont maintenant disponibles pour Centos6, Oracle6, CL6, Ubuntu16, et Centos8.4. D'autres suivront. Vous pouvez suivre le support de la distribution actuelle via le tableau de bord CVE ici : https://cve.tuxcare.com/cve/CVE-2021-4034.]

Cette vulnérabilité a été identifiée par leschercheurs de Qualyset divulguée aux distributeurs à la fin de l'année dernière, mais n'a été rendue publique que le 25 janvier 2022.

Il est extrêmement facile à exploiter et, alors que l'annonce initiale mentionnait qu'un exploit était susceptible d'apparaître dans les jours à venir, il n'a fallu qu'environ 3 heures pour que le code d'exploitation disponible publiquement soit découvert et confirmé comme fonctionnant. Il affecte les principales distributions Linux comme Ubuntu, RHEL, CentOS et leurs dérivés. Le code affecté faisant partie du code initial de polkit, publié en 2009, il est très probable que toute distribution utilisant polkit soit vulnérable.

Qu'est-ce que polkit (et pkexec) ?

Polkit est un paquetage qui fournit un contrôle des privilèges pour gérer la communication interprocessus lorsque les processus ont des niveaux de privilèges différents. Grâce à pkexec (un composant de polkit), cela permet à un utilisateur d'exécuter des commandes avec des privilèges plus élevés que la normale. Par exemple, il est possible de donner accès à un utilisateur spécifique pour effectuer une tâche à l'échelle du système sans lui donner un accès complet à la racine.

Un regard plus approfondi sur la vulnérabilité

Pkexec accepte les arguments qui lui sont passés dans la ligne de commande et qui contrôlent son comportement (quoi exécuter, quelle portée, etc.). Les chercheurs ont découvert qu'il était possible de passer un paramètre nul et de faire échouer le code qui valide le paramètre de telle sorte que la mémoire soit corrompue par une valeur contrôlée par l'attaquant et écrite dans l'environnement d'exécution de pkexec. Cela peut ensuite être étendu à l'exécution par pkexec de n'importe quelle commande en tant que root, ce qui est trivialement exploitable pour fournir un accès root complet à un utilisateur non privilégié.

L'analyse de code réelle est présente dans l'annonce initiale de Qualys, liée ci-dessus.

Atténuation avant qu'un correctif ne soit disponible

Il est possible d'atténuer le risque en supprimant le bit SUID de pkexec avec la commande :

Notez que cela interférera avec le fonctionnement régulier de pkexec. Veillez donc à tester minutieusement cette modification dans un environnement de test avant de l'adopter à grande échelle sur votre infrastructure, car elle peut entraîner des effets secondaires indésirables. Le correctif reste la meilleure option.

Remarques finales

Cette vulnérabilité nécessite un accès à un système pour être exploitée, car elle n'a pas de vecteur d'attaque à distance connu. Néanmoins, elle peut être utilisée par un attaquant qui obtient l'accès à un système pour ensuite élever ses privilèges. La prévalence de polkit en fait une menace de sécurité très sérieuse qui doit être corrigée dès que possible pour éviter les mauvaises surprises.

Cette vulnérabilité est un nouvel exemple d'un problème de longue date dans les logiciels libres : ce n'est pas parce que la source est ouverte que les bonnes personnes regardent. Le bogue était présent dans un code vieux de 12 ans, et personne ne l'a détecté pendant cette période - du moins, personne ne l'a annoncé publiquement. Les projets fondamentaux ont tendance à manquer de ressources (et d'incitation) pour auditer et sécuriser correctement leur code, mais d'innombrables autres projets et distributions s'appuient sur eux de manière disproportionnée. Pour mettre cela en perspective, un problème de sécurité dans un code vieux de 12 ans n'est même pas le "plus vieux" bogue trouvé ces derniers mois. Plus le code est audité, plus il est probable que d'autres failles seront découvertes, ce qui plaide en faveur d'une accélération de la correction des nouvelles vulnérabilités, dès leur apparition.

Les correctifs pour toutes les distributions couvertes par le service de support étendu du cycle de vie de TuxCare sont en cours de préparation et seront disponibles sous peu - revenez ici pour les mises à jour, car ce post reflétera la disponibilité des correctifs pour les différentes distributions dès qu'ils seront prêts à être déployés.