RHSB-2022-001 Escalade de privilèges de Polkit - (CVE-2021-4034)

Synthèse

Red Hat est au fait d'une vulnérabilité située dans pkexec qui permet à un utilisateur authentifié de réaliser une attaque par élévation de privilèges.

Le paquet polkit est conçu pour définir et gérer les politiques qui permettent aux processus non privilégiés de communiquer avec les processus privilégiés sur un système Linux. Pkexec, qui fait partie de polkit, est un outil qui permet à l'utilisateur d'exécuter des commandes en tant qu'autre utilisateur selon les définitions de la politique de polkit par la fonction setuid. La vulnérabilité trouvée dans pkexec permet à un attaquant local non privilégié d'élever ses privilèges, en contournant toute authentification et toute politique, en raison d'une gestion incorrecte du vecteur d'arguments du processus. 

Le principal risque pour les clients est la possibilité qu'un utilisateur non privilégié obtienne des privilèges administratifs sur les systèmes concernés. L'attaquant doit avoir un accès de connexion au système cible pour réaliser l'attaque.

Ce problème est classé CVE-2021-4034 avec un impact de gravité Important.

Les versions suivantes des produits Red Hat sont concernées. "Affecté" signifie que la vulnérabilité est présente dans le code du produit, indépendamment de l'utilisation ou des mesures d'atténuation qui peuvent être appliquées si le produit est vulnérable.

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Virtualization 4

De plus, tout produit Red Hat pris en charge par la plateforme Red Hat Enterprise Linux (y compris RHEL CoreOS) est aussi potentiellement impacté. Cela comprend :

• Les conteneurs de produits qui sont basés sur le paquet polkit de RHEL et ship. Ces images sont mises à jour régulièrement, et l'état des conteneurs indiquant si une correction de cette faille est disponible, peut être consulté dans le Container Health Index, qui fait partie du Red Hat Container Catalog.

• Les produits qui extraient des paquets du canal RHEL (cela inclut les produits en couches tels que Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, Red Hat Virtualization et autres). Assurez-vous que le paquet RHEL polkit sous-jacent est à jour dans ces environnements de produits.

Pour déterminer si votre système est actuellement vulnérable à ces failles, consultez la section Diagnostic ci-dessous. De plus, un Playbook Ansible est fourni ci-dessous pour la remédiation automatique.

Résumé technique

Le programme pkexec ne valide pas correctement la quantité d'arguments qui lui sont passés. Ce problème conduit éventuellement à des tentatives d'exécution de variables d'environnement en tant que commandes. Lorsqu'il est exploité correctement, ce problème permet à pkexec d'exécuter du code arbitraire en tant qu'utilisateur privilégié, ce qui permet à l'attaquant de procéder à une élévation locale des privilèges. Reportez-vous à CVE-2021-4034 pour plus de détails.

Mitigation

Red Hat Product Security recommande fortement aux clients concernés de mettre à jour le paquetage polkit dès qu'il est disponible. Pour les clients qui ne peuvent pas mettre à jour immédiatement, le problème peut être atténué en exécutant les étapes suivantes :

1. Installez les paquets et dépendances de systemtap suivants : https://access.redhat.com/solutions/5441.

2. Installer l'info de débogage de Polkit :

debuginfo-install polkit

3. Créez le script systemtap suivant, et nommez-le pkexec-block.stp :

probe process("/usr/bin/pkexec").function("main") {

if (cmdline_arg(1) == "")

raise(9);

}

4. Charger le module systemtap dans le noyau en fonctionnement :

stap -g -F -m stap_pkexec_block pkexec-block.stp

5. Assurez-vous que le module soit bien chargé :

lsmod | grep -i stap_pkexec_block

stap_pkexec_block 434176 0

6. Une fois que le paquet polkit est mis à jour vers la version contenant le correctif, supprimez le module noyau généré par systemtap en exécutant :

rmmod stap_pkexec_block

Après avoir utilisé la commande rmmod, un redémarrage du système n'est pas nécessaire.

Note : Si le système est redémarré, le module généré par systemtap doit être rechargé dans le noyau. Pour ce faire, accédez au répertoire où le script d'atténuation a été créé et suivez les étapes 4 et 5.

Une fois les mesures d'atténuation ci-dessus effectuées, pkexec continuera à fonctionner comme prévu pour les cas d'utilisation légitimes.

Remarque : cette mesure d'atténuation ne fonctionne pas pour les systèmes à démarrage sécurisé. SystemTap exigerait qu'un serveur de compilation externe ait la capacité de signer le module de noyau généré avec une clé inscrite dans le trousseau de clés du noyau.

Détails techniques

Lors du démarrage d'un nouveau processus, le noyau Linux crée un tableau avec tous les arguments de la commande (argv), un autre tableau avec les variables d'environnement (envp), et une valeur entière représentant le nombre d'arguments (argc). Le noyau Linux positionne le tableau des arguments et le tableau des variables d'environnement de manière contiguë dans la mémoire. Un autre comportement par défaut est que la première valeur du tableau d'arguments contient le nom de l'exécutable (ex. pkexec pour l'exécutable pkexec), ce qui implique que tout argument envoyé au processus par l'utilisateur est positionné après cette valeur.

Pkexec ne valide pas le nombre d'arguments, il suppose qu'il sera toujours au moins égal à 1, et que la seconde valeur est soit NULL, soit la commande à exécuter par pkexec en tant qu'utilisateur privilégié. Si un attaquant parvient à forcer le tableau d'arguments à être vide, pkexec interprétera le contenu du tableau d'environnement comme l'application à exécuter. Un attaquant peut en tirer parti en manipulant ces variables pour qu'elles contiennent des valeurs et des charges utiles spécifiques, ce qui permet de les exécuter en tant qu'utilisateur privilégié sans qu'aucune authentification ne soit demandée.

Impact sur les services

Les services Red Hat suivants sont directement affectés : 

• OpenShift Dedicated (OSD) 

• Azure RedHat OpenShift (ARO) 

L'impact sur les services est faible, puisque pour utiliser polkit, l'utilisateur doit utiliser un graphique ou une CLI pour s'authentifier afin d'obtenir un service avec polkit agissant comme agent d'authentification. Dans l'OSD, l'utilisation graphique n'est pas pertinente ; dans l'utilisation CLI, l'utilisateur utilisera la commande OC pour s'authentifier auprès du cluster OSD.

De plus, l'OSD ne fait pas d'utilisation particulière de polkit dans les clusters de production. Dans OSD, sur l'un des maîtres du cluster OSD de test, timedatex a une dépendance sur polkit. Par conséquent, pour l'OSD/ARO, l'impact est faible.

Mises à jour pour les produits affectés

Il est fortement recommandé aux clients de Red Hat utilisant des versions affectées de ces produits Red Hat de les mettre à jour dès que les errata sont disponibles. 

Les clients sont invités à appliquer immédiatement les mises à jour disponibles et à activer les mesures de mitigation de l’impact qu'ils jugent appropriées.  

[^1] Un lien vers les avis/mises à jour sera ajouté dès que les mises à jour seront disponibles.

^[2] Qu'est-ce que l'abonnement à Extended Update Support (EUS) de Red Hat Enterprise Linux ?

[3] ^{Qu'est-ce que Advanced mission critical Update Support (AUS) ?}

^{[4] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux SAP Solutions ?}

[^5] Un abonnement actif à Extended Life-cycle Support (ELS) est nécessaire pour accéder à ce correctif.  Veuillez contacter le service commercial de Red Hat ou votre représentant commercial spécifique pour plus d'informations si votre compte n'a pas d'abonnement ELS actif.

Diagnostic

Un script de détection a été développé afin de déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier l'authenticité du script, vous pouvez également télécharger la signature OpenPGP détachée. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client.

Playbook Ansible

En outre, il existe un Playbook Ansible disponible qui automatise les mesures d'atténuation décrites ci-dessus. Ce playbook va installer les paquets nécessaires à l'utilisation de systemtap, puis va créer et installer un script systemtap pour empêcher l'utilisation de la commande pkexec sans arguments. Cette mesure d'atténuation devra être réappliquée après un redémarrage, ce qui peut être réalisé en réexécutant le playbook.

Pour utiliser le playbook, définissez la variable supplémentaire HOSTS avec le nom d'inventaire Ansible des hôtes auxquels l'atténuation sera appliquée. Par exemple,

ansible-playbook -e HOSTS=web,ns1,mail CVE-2021-4034_stap_mitigate.yml

Pour vérifier l'authenticité du playbook, vous pouvez télécharger la signature OpenPGP détachée. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client. 

FAQ

Q : Après avoir appliqué le correctif, est-il nécessaire de redémarrer un service ou un système pour s'assurer que le système ne soit pas vulnérable ?

R : Il n'est pas nécessaire de redémarrer un service ou le système. Le correctif est appliqué sur pkexec, qui est un outil de la suite polkit. Il s'agit d'une exécution à une seule instance, et une fois la mise à jour appliquée, la prochaine fois que pkexec sera exécuté, il devrait charger l'application corrigée. Lorsque la mise à jour est appliquée, le processus de mise à jour redémarre le service polkit.

Q : Est-il nécessaire de redémarrer le système ou le service après avoir appliqué les mesures d'atténuation recommandées ?  

R : Il n'est pas nécessaire de redémarrer le système après avoir appliqué les mesures d'atténuation. Systemtap lui-même s'assurera que le module kernel est chargé.

Q : Est-il possible de supprimer la permission setuid du binaire pkexec comme mesure d'atténuation ?

R : Red Hat ne recommande pas d'enlever le bit setuid car cela causerait une rupture du système. La suppression de la permission setuid du binaire pkexec l'empêchera de fonctionner correctement pour les cas d'utilisation légitimes. Cela signifie que toute application qui repose sur l'exécution de pkexec cessera de fonctionner, provoquant éventuellement des erreurs système et un comportement inattendus. Bien que l'avis de Qualys sur cette vulnérabilité mentionne la suppression de setuid comme mesure d'atténuation potentielle, il a été déterminé qu'il ne s'agit pas d'une mesure d'atténuation viable pour nos clients sans provoquer de rupture. Red Hat a fourni une atténuation alternative qui, lorsqu'elle est appliquée, n'a pas d'impact négatif sur la fonctionnalité de pkexec. Toute mesure d'atténuation utilisée ne doit l'être qu'à court terme, jusqu'à ce que les correctifs publiés puissent être appliqués.

Q : Quel est l'impact sur la plateforme OpenShift Container Platform ?

R : Dans OpenShift Container Platform (OCP), le paquet polkit est livré dans le RHCOS, qui est utilisé dans les nœuds de cluster. L'accès aux nœuds OCP est limité aux administrateurs du cluster. Si quelqu'un peut se connecter directement au noeud OCP, et sera déjà un utilisateur root, alors l'existence du paquet vulnérable polkit ne change rien.

Le paquet polkit est également livré dans plusieurs images de conteneur OCP utilisées par les administrateurs de cluster pour gérer le cluster OCP. Ces images sont exécutées en tant que conteneurs privilégiés, de sorte que toute personne pouvant accéder à ces conteneurs dispose déjà d'un accès administrateur total,

Q : J'exécute Red Hat Enterprise Linux 7.x avec Docker. Après le redémarrage, mes conteneurs ne sont plus accessibles par le réseau. Que dois-je faire ?

R : Lorsque Docker démarre, il définit net.ipv4.ip_forward à 1, ce qui permet la redirection IP, nécessaire pour rendre les conteneurs accessibles sur le réseau. Cependant, il n'est pas conservé dans la configuration de la machine. Lors de la mise à jour du paquetage polkit, le service polkit redémarrera automatiquement sur le serveur Red Hat Enterprise Linux et finira par déclencher le rechargement de la configuration du noyau par le système. Cela remplace les entrées sysctl non persistantes, ce qui rend les conteneurs Docker inaccessibles sur le réseau. Pour éviter un tel comportement, l'administrateur système doit s'assurer que la valeur souhaitée de net.ipv4.ip_forward est persistée dans les fichiers de configuration sysctl. Voir Comment définir les variables sysctl sur Red Hat Enterprise Linux pour plus d'informations concernant cette procédure.

Remerciements

Red Hat remercie l'équipe de recherche Qualys pour avoir signalé cette vulnérabilité.

Références

https://access.redhat.com/security/cve/CVE-2021-4034

https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

Comment utiliser le GPG pour vérifier le contenu signé de la Sécurité produits