La vulnérabilité réside dans le composant Polkit. Nommé précédemment PolicyKit, il est responsable dans les systèmes de type Unix et Linux des interactions entre les processus sans privilèges et ceux qui en ont, de manière à ce que ces communications soient sécurisées. Via pkexec, il permet également de lancer des commandes avec des privilèges élevés.
Dans un billet, la société Qualys annonce qu’une faille remontant à 2009 était présente dans ce composant-clé. Elle a été découverte en novembre, mais n’a été rendue publique que mardi soir. Une attente destinée à laisser le temps à la majorité des systèmes concernés de se mettre à jour.
La faille est en effet considérée comme simple à exploiter et fiable à 100 %. En clair, il suffirait qu’une personne ait un pied dans la place pour obtenir les droits root par escalade des privilèges. Un malware quelconque pourrait alors être exécuté avec les droits maximum.
La faille, nommée PwnKit par Qualys, porte la référence CVE-2021-4034.
Le développeur Ryan Mallon a cependant indiqué dans un tweet qu’il avait évoqué cette faille en 2013 déjà, billet de blog à l’appui. Il dit avoir trouvé la source du problème, mais n’avait pas pu, à l’époque, trouver de méthode d’exploitation. Il avait cependant écrit un patch, dont il fournit également le code.
Quoi qu’il en soit, toutes les distributions principales sont maintenant à jour. Il suffit de s’assurer que l’on a bien récupéré les derniers correctifs.
Commentaires (59)
#1
Il n’existe aucun système infaillible, tout simplement parce que des humains, écrivant leur code, sont faillibles… Open source ou pas.
#1.1
Oui et non. Même avec des humains «infaillibles» il y aura toujours des limites à un système je pense.
#2
On m’aurait menti ? LINUX n’est pas invulnérable aux logiciels malveillants ?
#2.1
C’est Polkit que tu appelles un “logiciel malveillant” ? Un peu, oui.
#2.2
Il ne l’a jamais été :)
Maintenant, il s’agit d’une vulnérabilité locale. Aucun système n’a été épargné ces dernières années.
#2.3
Le problème est toujours le même : si tu veux être invulnérable, l’utilisateur doit être restreint dans ce qu’il peut faire. Un utilisateur lambda ne peut pas installer le moindre périphérique, changer les mount points, ou même changer la résolution de l’écran, etc. Tout ça doit se faire en se connectant comme root. Comme c’est totalement invivable, il a bien fallu trouver un moyen d’élever temporairement les privilèges d’un utilisateur pour lui permettre d’administrer sa machine… La boîte de pandore est ouverte…
En ce temps là, sudo et consorts n’existaient pas… Tout se passait par le flag sui.
Et ton terminal, tu le configurais par 8 dip switches à côté de la prise RS-232…
#3
J’attendais avec impatience l’Idiot du Lac ! Il m’a un peu déçu, il n’est que troisième à commenter, mais le contenu est tel que je l’attendais.
#4
Comme dit Akta, c’est une vulnérabilité locale.
Il est loin le temps où les utilisateurs avaient tous des comptes sur un serveur unix/linux commun, avec un accès via un terminal. Auquel cas cette faille aurait été une catastrophe !
On est dans une époque ou chacun à son propre “serveur” unix/linux et les échanges se font par des services (avec une convergence vers http over tcp/ip).
#4.1
je ne comprends pas la notion de “vulnérabilité locale”, tous les postes sans exception sont éligibles à être vulnérables localement, soit il suffit qu’ils se connecte à un site qui injecte du code avec des droits minimes au départ, soit quelqu’un infecté s’y connecte, non ?
#4.2
“Locale” n’est pas forcément le bon terme.
Par là il entend qu’il faut avoir un accès pré-existant au serveur, pour pouvoir exploiter cette vulnérabilité. SI tu n’as pas déjà un compte sur la machine (légitimement ou non), ce n’est pas avec cette vuln que tu vas avoir des accès root.
#5
Mais du coup, les téléphone Android sont également touchés ?
Qu’est-ce qui va se passer ?
#5.1
Pas vraiment aussi simple. Pas de panique.
Et puis s’élever en Root sur un système qui t’appartient déjà… mwala.
Pour un téléphone pro c’est pas mieux non plus.
#5.2
mais alors je peux devenir root sur mon smartphone
, sans me casser les bonbon à changer l’image et perdre la garantie !!!
mon dieu ! c’est génial ! decidement ce linux est magique !
#5.3
Tu ne perds pas la garanties matériel quand tu root ton phone, bienvenue en Europe.
#6
Perso pour moi PolicyKit est une usine à gaz infâme, j’ai mis très longtemps à pouvoir ne serait-ce que le comprendre pour l’utiliser a minima.
Ca ne me surprend pas du tout que vue la complexité du bouzin, il y ait des failles.
#7
“Is this vulnerability remotely exploitable?
No. But if an attacker can log in as any unprivileged user, the vulnerability can be quickly exploited to gain root privileges.”
#8
sudo existe quand même depuis 40 ans, donc plus vieux que Linux.
#8.1
OK, je me rappelais de
sumais pas desudo(note que si la commande su existe, sudo n’est forcément pas loin…)#9
Ah ben je le veux bien le dip switch pour passer root sur smartphone
#9.1
Il permettait de régler la vitesse, le nombre de bits (7 ou 8), la parité, des trucs comme ça.
#9.2
Ha oui, ce que moi j’appelle Terminal, c’était un Televideo 910. Le sens a un peu évolué depuis
#10
Pfft !
Pour moi, c’est ça.
#10.1
Mon expérience ne remonte pas plus loin que …
https://fr.wikipedia.org/wiki/Carte_perfor%C3%A9e#/media/Fichier:Lochkartenauswerteger%C3%A4t_IBM_mit_Bedienstation.jpg
#11
Disons que ces derniers temps c’est rarement aussi trivial. Et je pense exploitable en python (appel à setgid possible).
La démo d’exploit, c’est même pas 20 lignes de C (7-8 pour un programme à compiler, 2 pour lancer pkexec avec les paramètres pour lancer le programme de 7-8 lignes).
Pas eu le temps de regarder hier, mais si pkexec est sur la tablette/teléphone, je pense que ça peux fonctionner.
Remarque drôle: sous Windows, télécharger le code source ou l’exécutable de kits comme ceux pour casser les MDP est signalé/bloqué par l’antivirus. Télécharger des failles linux non.
#12
https://fr.wikipedia.org/wiki/Terminal_(informatique)
#12.1
Oh une VT100, j’ai bossé là dessus … et ça c’était solide, vraiment solide.
#13
openbsd > all.
Period.
#14
xenix > gnu hurd > openbsd > all
#15
La faille ça ne m’étonne pas, un logiciel c’est comme un fromage : plus y’a de trous plus y’a de gruyère, c’est juste normal. Module les bonnes pratiques : une Vache qui rit au fromage reconstitué c’est forcément moins bon qu’un Saint Nectaire fait avec amour.
Ce que je trouverais intéressant c’est de savoir à posteriori pourquoi cette faille n’a été traitée que récemment. Ce n’est pas pour blâmer qui que ce soit, plutôt pour comprendre un peu mieux comment un tel projet se gère, tant sur le plan tech qu’humain. Il y aurait probablement un enseignement à tirer de cela, sinon c’est voué à se répéter.
#16
Après, pkexec est la porte d’entrée trouvée ce coup-ci, mais la vraie vulnérabilité est dans le kernel Linux (accepter NULL comme valeur valide pour argv, ce que bizarrement aucun autre *NIX ne fait…).
Donc là on patch PolKit, mais il suffit de trouver un autre binaire avec le flag setuid qui ne gère pas correctement le cas de figure argv=NULL et on a une autre porte d’entrée.
En 2007 quelqu’un a proposé de corriger ce comportement aberrant du kernel, ça a été refusé: https://bugzilla.kernel.org/show_bug.cgi?id=8408 .
#16.1
La raison du refus n’est elle pas aberrante aussi ?
#16.2
Oui, voir mon commentaire plus haut.
#16.3
C’est une des principales règles de dev sur le kernel Linux : Do no break userspace
Donc ses explications sont fumeuses, comme indiqué par fred42, mais surtout corriger le bug pourrait faire que d’anciens programmes ne fonctionnent plus (modification de l’ABI, Application Binary Interface). Et ça, dans la team kernel Linux, ça ne se fait pas. Sinon tu te fais engueuler par Torvald.
#17
Je ne savais même pas que ca existait ce raccourci “NULL = pointeur sur NULL”.
J’ai toujours créé des pointeurs quand on demande un pointeur.
Génération Kernighan and Ritchie \o/
#17.1
Le père Alan surtout raconte 2 bêtises en affirmant “NULL is a valid pointer in some cases, it points to a page which contains NULL as its start so happens to be a valid argument vector, by chance.”.
#18
Les admins Linux, faites un petit
find /usr/bin -perm -4000 | wc -lsur vos machines, pour voir le nombre de binaires avec le flag setuid (n’hésitez pas à adapter le path de la recherche en fonction de votre distro/environnement).Sur un CentOS 7 assez standard, j’en compte 12 (dont pkexec) dans /usr/bin, et 3 dans /usr/sbin.
Autant de portes d’entrée potentielles.
#18.1
11 sur mon ubuntu dans /usr/bin et 1 dans /usr/sbin (pppd), dont 5 pour modifier les fichiers passwd, group et fichiers shadow associés, me semble peu de risque qu’ils appellent exceve.
3 pour des fonctions réseaux : idem en terme de risque.
v4l-conf : peu de risque aussi.
Restent pkexec, sudo et at.
#18.2
Pas besoin qu’ils appellent execve. Juste qu’ils parsent argv sans se soucier d’une potentielle valeur nulle dans argv[0] et effectuent des actions en se basant sur cette valeur.
execve est l’appel utilisé par le logiciel malveillant exploitant la faille.
Par exemple, dans ce PoC (https://haxx.in/files/blasty-vs-pkexec.c) on trouve cette ligne de code:
#19
D’ailleurs, dans le patch de pkexec qui colmate cette CVE, ils n’ont pas touché à l’appel execv (et non execve), présent ligne 1020.
Ils se contentent de bien vérifier argc et argv.
#20
Mauvais deuxième lien… https://gitlab.freedesktop.org/polkit/polkit/-/blob/a2bf5c9c83b6ae46cbd5c779d3055bff81ded683/src/programs/pkexec.c#L1020
#21
À l’époque (je parle en particulier des années 90) c’était un jeu pour les étudiants de mon école, du moins les plus geeks, de trouver des faille pour faire de l’évolution de privilège. Il y en avait un qui avait même fait une version graphique, qu’il avait appelée “xsu” (en X/OpenLook sur Sun Sparc), qui permettait de faire ouvrir, d’un clic sur un nom (login), un terminal logué sous l’utilisateur en question.
À l’époque dès qu’on avait des manipulations à faire en root, soit on se connectait directement en root, soit on utilisait “su” ou “su -”. Après des années de pratique, ça a un peu changé sous Linux, et à présent je fais “sudo -i”.
J’ai appris avec le K&R mais pour moi NULL ça sert justement quand on parle de pointeur NULL (et on fait des comparaisons avec cette valeur).
#22
En tous cas, ne pas vérifier le
Oui, ça a permis dans le temps (je parle des 90) pas mal de contournement de sécurité, et justement ça a conduit à un comportement beaucoup plus strict des commandes “setuid”, par exemple un démarrage comme “root” puis assez rapidement le processus effectue une baisse de privilège (n’est plus root mais un autre compte).
Un truc marrant c’était avec l’utilitaire “finger” qui allait lire le fichier ~/.plan . Il suffisait de créer un lien symbolique sur son compte utilisateur de “.plan” vers n’importe quel fichier (même seulement lisible pour root) pour in fine lire le fichier.
Je trouve ça dingue qu’il y ait encore des programmes qui ne vérifient pas les entrées. Même sans parler de malveillance il y a déjà l’erreur humaine.
#23
Techniquement, ils font des vérifications sur les entrées.
Là le soucis c’est que Linux ne respecte pas POSIX, et laisse argv être juste un pointeur vers NULL (là où n’importe quel UNIX balance un EFAULT et crash le programme, car il devrait toujours y avoir au minimum le nom du programme appelé).
Vu que ce n’est pas quelque chose de connu, les devs ne devaient même pas savoir qu’une telle vérification était nécessaire.
#24
Les devs du kernel Linux vont apparemment patcher ça, 15 ans après que ça leur ait été remonté une première fois et qu’ils aient refusé de patcher cette non conformité POSIX…
https://lore.kernel.org/lkml/[email protected]/
#25
Tu peux aussi abandonner cette habitude et charger l’environnement
rootvia ta commande et lancer toutes tes commandes depuis l’espace utilisateur en préfixant toutes tes commandes avecsudo.Je ne deviens jamais root dans les systèmes m’appartenant, et j’essaie de l’éviter autant que faire se peut dans les bousins que j’administre.
#26
J’ai qqes VM debian, de la dev,un peu de prod sur du proxmox.
Pour maj ça, je peux faire du
Apt update && Apt upgrade -y
Sur le proxmox et sur les guests et c’est fini?
C’est quoi vos habitudes ?
#27
Stricto sensu, le souci c’est que le code va faire un “monkey patch” dans le tableau argv pour y substituer le nom de l’exécutable. Ce tableau ne lui appartient pas et ne devrait pas pouvoir être modifié… Tu veux une variable avec le nom de l’exécutable, tu t’en crées une, mais tu ne vas pas patcher argv…
Sans compter que faire comme il font génère très probablement un memory leak (d’accord on s’en fout un peu en pratique, mais en théorie c’est caca)
#28
Pour un attaquant qui veux infecter un système distant (=ton PC), ca veut dire qu’il faut d’abord qu’il exploite une 1ère vulnérabilité qui lui permet d’exécuter une commande en local, puis qu’il exploite cette nouvelle vulnérabilité pour passer root.
#29
Pardon mais c’est complètement stupide. Aucun intérêt. Si je veux bosser comme utilisateur privilégié, je me mets sous cet utilisateur et je bosse comme ça (parce que j’ai plusieurs commandes à lancer).
Taper “sudo” devant chaque commande, c’est juste chiant pour RIEN.
Ben quand tu tapes “sudo”, tu deviens root !
#30
Ce n’est pas parce que tu n’en comprends manifestement pas l’intérêt que c’est stupide.
Je pensais te fournir un conseil utile. Mes excuses pour avoir ainsi eu l’audace de tenter de bousculer hypothétiquement tes habitudes bien établies, ainsi que ton expertise.
Non.
Le processus que tu lances bénéficie, lui, de l’environnement de l’utilisateur cible (par défaut
root). Tu ne quittes pour ta part jamais ton environnement utilisateur.Avec
sudoconfiguré de manière agressive afin d’exiger l’authentification de l’utilisateur source de la demande (ce qui n’est pas le cas par défaut), il est donc impossible à n’importe qui/quoi ayant accès à l’environnement/le terminal de l’administrateur, même temporairement, d’exécuter une charge utile avec l’environnement d’un autre utilisateur.#31
Non, tu ne sais pas ce qu’est sudo apparemment.
Quand tu vas editer le fichier sudoers, tu peux voir que tu peux :
Tu restes toujours dans ton environnement utilisateur propre avec sudo.
Pourquoi crois-tu que certaines distributions restreignent ou desactivent carrément l’utilisateur root en accès direct ?
Franchement, c’est la base d’une gestion saine de l’administration sous Linux.
#31.1
Merci les gars de m’expliquer le fonctionnement de sudo et l’existence du fichier sudoers…
Non mais sérieusement…
#31.2
(c’était pas vendredi.. non ça va. Je peux essayer une théorie)
Je pense qu’OlivierJ sait globalement très bien ce que permet sudo. C’est juste qu’il répondait à Berbe dont le message était dans un contexte d’utilisation de sudo pour lancer quelque chose avec les droits root. Pas une dissertation sur l’ensemble des possibilitées de sudo.
Mais, c’était pas une raison pour dire que c’est stupide.
D’autant que je suis plutôt d’accord avec Berbe.
Et aussi avec SebGF, ci-dessus. moins on manipule le mot de passe root mieux c’est.
Si sudo demande à l’utilisateur son mot de passe, ça protège de quelqu’un/quelque chose qui aurai accès à l’environnement de l’utilisateur sans le mot de passe (session pas verrouillée, ou élévation de privilège via une faille, mais donc sans le mot de passe)
Si au contraire on est régulièrement logué root, ça facilitera la tâche d’un opportuniste (ou pire) qui accède à l’environnement de l’utilisateur.
Cela-dît, le sudo pour ce genre de commande
echo 1 >/proc/sys/kernel/sysrqva tout de suite être moins sympathique.J’ai pas compris cette histoire de mot de passe root à l’install ?
Si c’est toujours dans le contexte d’un sudo pour lancer des chose avec les droits root. Autant utiliser directement un
su -avec le mot de passe root, pas besoin de passer par un sudo.Et si le mot de passe root a changé depuis l’install. Le fait de garder le mot de passe d’origine pour le sudo, donc sans jamais le changer, m’échappe complètement.
#32
Vu que je connais sudo, ce n’était pas utile.
ça ne veut rien dire ; ça lance sous “root” la commande de ton choix. Aucune différence pratique avec le fait de taper “sudo -i” avant et ensuite la même commande.
Par défaut sur mes distributions, le sudo me demande le mot de passe root utilisé à l’installation.
Bref, je ne comprends pas qu’on puisse voir un intérêt à préfixer plusieurs commandes d’affilées avec “sudo”.
#33
Tu nous dis que quand tu tapes sudo tu deviens root, c’est tout simplement faux.
Moi j’ai des commandes que, quand je les lance avec sudo, sont lancées avec les privileges d’un autre utilisateur que root.
Donc oui, sérieusement.
#34
@sanscrit
En même temps, j’ai toujours été root sous mon pinephone…
Il faut juste choisir de ne pas céder à google ou apple, et être prêt à sacrifier un peu de confort pour beaucoup de liberté. Ça reste un choix.
#35
C’est un raccourci un peu violent quand même de dire ça. Si comme
sula commande donnerootpar défaut, son but premier reste d’exécuter une commande avec les droits d’un autre user.sudo, sudoedit — execute a command as another user(source : man)
Typiquement, le user
apacheest généralement affublé d’un/sbin/nologincomme shell par défaut, indiquant qu’il est interdit de se connecter avec. On peut cependant utilisersudopour lancer des actions en son nom.Ce qui fait que
sudopermet une élévation de privilège, c’est parce que la commande possède la permission SetUID et qu’elle est propriété deroot. De ce fait, son invocation lui garantie systématiquement les droitsroot.Sur ma Fedora :
Mais elle ne fait pas devenir
rootsi l’action invoquée est avec un autre profil utilisateur (cf l’exemple Apache).Ca c’est pas normal, c’est le mot de passe de l’utilisateur invoquant la commande qui est demandé (sauf si l’action est préfixée NOPASSWD). A moins que l’utilisateur admin créé lors de l’install ait le même mot de passe que
root(ce qui dans ce cas est une très mauvaise pratique), ça me paraît anormal de devoir connaître le mot de passe deroot. Je sais que certaines distributions proposent à l’install d’assigner àrootle même mot de passe que l’utilisateur initial, mais c’est crade.C’est justement tout l’intérêt de
sudo: ne pas divulguer le secret des autres profils.Son autre intérêt donner juste ce qu’il faut comme droit à des utilisateurs, puisque comme le dit le proverbe : l’erreur est humaine, la vraie catastrophe nécessite le mot de passe root.
#36
sudoedit /proc/sys/kernel/sysrqpermet d’éditer le fichier, mais ça implique des actions supplémentaires puisque ça ouvre l’éditeur par défaut plutôt que de rediriger depuis la StdIn.Après, c’est dans le monde des bisounours, mais dans un contexte d’entreprise l’admin système sera le seul à avoir accès à
rootet idéalement, via un bastion qui maîtrise son credential. Et dans la vraie vie il est juste dans un Excel sur un drive partagé, la routine habituelleAllez, une dernière pour la route..
#36.1
Merci, je ne connaissais pas
)
sudoedit. Ça a l’air mieux qu’unsudo vi, mais quand même moins pratique qu’une redirection dans pas mal de situations et ne semble pas fonctionner pour un fichier interdit à la lecture, mais autorisé à l’écriture.Ici, il y a plusieurs méthode, j’essaierai de me souvenir du
echo 1|sudo tee /proc/sys/kernel/sysrqla prochaine fois que j’en aurai besoin.(ça m’énerve, j’aurai dû y penser, ou faire la recherche hier