[résolu] faille de sécurité PwnKit

totoZero7 · 26-01-2022 19:45:46

Bonjour,

Je lisais une news sur la faille de sécurité PwnKit
dispo ici
https://www.clubic.com/linux-os/debian/ … kexec.html

Selon l'article, celle-ci pourrait exister depuis 12 ans et permet en 1 simple ligne de commande d'obtenir les droits root. Plutôt ouf comme nouvelle.

Ce qui est mis en cause serait un programme "Polkit pkexec" installé sur toutes les machines.
Cette faille semble avoir été bouchée par Debian le 25/01/2022 si je dis pas de bétise.

Sur mon OS, je n'ai pas encore fait la mise à jour et j'ai voulu tester cette fameuse commande mais cela ne fonctionne pas. J'ai un message d'erreur.

La commande en question est:

gcc exp.c -o exploit

gcc: error: exp.c: Aucun fichier ou dossier de ce type

gcc: fatal error: no input files

J'ai vérifié si j'avais le paquet Polkit

dpkg-query -W |grep polkit

libpolkit-agent-1-0:amd64 0.105-31

libpolkit-gobject-1-0:amd64 0.105-31

mate-polkit:amd64 1.24.0-2

mate-polkit-common  1.24.0-2

j'ai ensuite vérifié si j'avais le fichier exp.c et là je n'ai rien trouvé

find / -type f |grep "exp.c"

rien trouvé, enfin si, un truc qui a les mêmes lettres mais je ne pense pas que cela soit ce que je cherche

/usr/src/linux-headers-5.10.0-5-common/include/net/netfilter/nf_conntrack_expect.h

Ma question c'est, comment ça se fait que je n'ai pas ce fichier étant donné que c'est logiquement un logiciel déjà installé ou est-ce qu'il peut avoir un autre nom ?

Dernière modification par totoZero7 (26-01-2022 22:34:54)

Tawal · 26-01-2022 21:57:00

Hello,

Le fichier exp.c est importé par le pirate (il a besoin de ce fichier [ou du moins du code qu'il contient] pour exploiter la faille).
Il est précisé que cette faille n'est pas exploitable à distance mais que sur des machines physiques (le pirate a un accès physique à la machine).
Ce fichier exp.c est un fichier de code source en C. Il peut s'appeler n'importe comment et peut être compilé en 1 fichier binaire portant n'importe quel nom.

D'ailleurs, je trouve que ça manque d'informations : la taille et le contenu du fichier exp.c par exemple.
Car il est dit qu'une seule ligne de commande suffit pour obtenir les droits root. Or, j'en vois au moins 2 : la commande pour compiler le fichier, et l'autre pour "lancer" l'exploit.
Mais si le fichier exp.c contient 3000 lignes de code, au final cette faille n'est peut-être pas si simple d'accès.
Si, au contraire, il ne contient qu'une dizaine de lignes, alors ce n'est plus la même chose.
Toujours est-il que ce fichier a besoin d'être importé sur la machine pour pouvoir exploiter la faille.
On en revient encore à la même chose : ne pas télécharger n'importe quoi n'importe où, éviter les logiciels tiers (non compris dans les dépôts) et toujours le comportement de l'interface chaise-clavier ...

Dernière modification par Tawal (26-01-2022 21:57:20)

totoZero7 · 26-01-2022 22:32:41

Waou, Merci Tawal pour ces explications.

Je ne sais pas où t'as eu connaissances de tout ça mais ce que tu dis est bien plus clair est complet que l'article que j'ai cité.
C'est d'ailleurs un site web connu pour des résumés vraiment très succincts qui sont à la limite de la malinformation (je le prouve en écrivant ce post) par justement, son manque d'information. Mais bon, c'est facile et rapide à lire et c'est là où on peut chopper les derniers potins ou on peut lire en diagonale avant d'investiguer plus XD (je dis ça pour me justifier d'aller dessus)

Donc en fait, j'ai à moitié flippé pour rien car il faut se fameux fichier pirate, que je suppose peu de monde a.
Ce post sera d'interêt public pour être rassuré et comprendre.

merci

Dernière modification par totoZero7 (27-01-2022 14:57:45)

ubub · 27-01-2022 00:05:45

Bonsoir,
@totoénzero si tu veux, t'as aussi les 'news' de sécurité de debian qui sont en général traduites en français (à chercher là haut en cliquant sur debian etc ..) tu pourras peut-être trouver ta réponse pour savoir comment ça a été pris en charge par l'équipe de debian ...

https://www.debian.org/security/
à toi de chercher ...

Dernière modification par ubub (27-01-2022 00:40:04)

totoZero7 · 27-01-2022 01:29:27

Merci ubub pour ta contribution à aller chercher sur le site de debian.org à la section "Mises à jour de sécurité". C'est une excellente démarche en effet.
Cependant, j'ai déjà visité le lien que tu as mis, avant de poster mon message et j'ai donc pu voir qu'il y avait un correctif à ce sujet, mais, il n'y avait pas l'explication sur son fonctionnement comme l'a magnifiquement décrit Tawal.
C'est en cela, n'étant pas un geek et n'ayant pas trouvé la réponse sur debian.org, que j'ai fait cette démarche de venir poser la question ici afin de comprendre.

naguam · 27-01-2022 01:32:46

https://access.redhat.com/security/vuln … B-2022-001 et https://access.redhat.com/security/cve/CVE-2021-4034
Je trouves que ces liens sont suffisants pour expliquer vaguement la faille et dire, il faut patcher. (lien qui m'a fait découvrir la commande stap)

Voici un lien qui explique dans le détail la faille:
https://blog.qualys.com/vulnerabilities … -2021-4034

J'avais commencé à détailler à la main la faille (ça fait 2h que je suis en train de tapper le post) mais j'ai retrouvé le lien (que j'avais perdu) ci-dessus qui l'explique mieux que moi alors voilà, cadeau.

totoZero7 · 27-01-2022 01:41:51

naguam a écrit :

J'avais commencé à détailler à la main la faille...[]

Tu peux toujours continuer à le faire si ça te plaît car les liens cités sont en anglais et c'est un blocage pour beaucoup de personnes.
Merci pour le retour à tous

naguam · 27-01-2022 02:19:42

Ok bon je vais m'y essayer à expliquer cette faille qui permet une élévation de privilège d'un user à root

J'espère ne pas me faire trop tapper dessus pas des personnes plus compétentes mais je me lance.

TLDR :

- Buffer overflow quand argc vaut 0
- Exploitation du buffer overflow via modification de la première var d'env et du PATH pour que l'overwrite de l'overflow soit de la bonne longueur pour entrer LD_PRELOAD à l'adresse d'une var d'env
- Injection possible de shared Library frauduleuses en SUID

Bases :

Setuid ou SUID :

- Déjà pour les débutants, il est important de comprendre le setuid :
- https://fr.wikipedia.org/wiki/Setuid
- https://fr.wikipedia.org/wiki/Permissions_UNIX)
Le setuid doit également être pris en charge au niveau du code (comme ça ça permet de ne l'utiliser que sur des parties voulues et limiter la quantité de code sensible)
Évidemment sans le droit Unix qui va bien : même pris en charge dans le code le setuid ne peut pas être utilisé.
Ça peut paraître idiot de permettre à un utilisateur d'exécuter un binaire avec les droits de l'owner (et non du user qui exécute), mais ça a son utilité faut juste que ce soit pas fait n'importe comment.

C pour comprendre :

- Maintenant, la base des bases du langage C :
- Fonction d'entrée du programme, la première exécutée, est main et peut prendre aucun ou plusieurs paramètres: argc et argv (et parfois envp)
argv c'est un tableau de chaînes de caractères qui correspondent aux arguments de la ligne de commande (le -l de ls -l par exemple) et se termine par un délimiteur NULL.
argc leur nombre (sans prendre en compte NULL)
envp c'est l'environnement mais même non spécifié, ça n'empêche pas le programme d'en avoir un.

Chaîne de caractères c'est équivalent à mot/phrase pour les débutants
D'ailleurs pour ceux qui ne le savent pas, j'ai oublié de le préciser, généralement un tableau démarre au rang 0 et non au rang 1.
Exemple de tableau classique argv :
["ls", "-l", "-a", "-h", NULL]
[0] [1] [2] [3] [4]

Vous remarquerez, que comme dans pas mal de langages, le premier élément est souvent le nom de l'exécutable.

Il faut cependant savoir que c'est pas obligatoire d'avoir des arguments en argv notamment en C. (et oui pas obligé d'avoir même le nom du binaire)
Par exemple sous linux et pas mal d'os, avec la fonction execve en C il est possible d'exécuter un binaire avec un argv vide (Dont l'unique élément est NULL) et donc d'avoir un argc à 0.

(Ce n'est pas possible sous OpenBSD apparemment, donc ils ne sont pas touchés comme indiqué dans l'article après même si c'est cool dans un sens ici la faille est due au code de polkit et non aux choix des os, après c'est à débattre mais ici ce n'est pas le sujet)

Shared librairies :

- Je conseille aussi de se renseigner sur les shared librairies et notamment la variable d'environnement LD_PRELOAD

Explication de la faille :

Les bases sont importantes pour comprendre la suite, n'hésitez pas revenir à passer du temps dessus.

En gros la partie de polkit qui a la faille c'est la partie pkexec dont l'owner est root et a un setuid. Code complet ayant encore la faille (car latest commit de 2014) pris sur un github random

Je vais reprendre le code du lien en anglais car c'était plutôt pratique :

        int

/*435*/ main (int argc, char *argv[])

/*436*/ {

         guint n;

/*...*/

/*534*/   for (n = 1; n < (guint) argc; n++)

/*535*/     {

/*...*/

/*568*/     }

/*...*/

/*610*/   path = g_strdup (argv[n]);

/*...*/

/*629*/   if (path[0] != '/')

/*630*/     {

/*...*/

/*632*/       s = g_find_program_in_path (path);

/*...*/

/*639*/       argv[n] = path = s;

/*640*/     }

Explication du code dans le cadre de la faille, c'est à dire lancé avec argc = 0

1) Voir ligne 534 si argc vaut 0 alors 1 est quand même assigné à n au niveau du for, bien qu'on entre pas dedans vu que la condition de boucle n'est pas validée.

2) Voir ligne 612, g_strdup va tenter de dupliquer la chaîne de caractère étant dans argv au rang n

3) Problème : voir 1) vaut 1 dans le for et donc en gros il va accéder à la mémoire adjacente à argv dont il n'a en théorie pas le droit de lire et va tenter de le lire comme chaîne de caractères
(vu que argv[0] vaut NULL et que c'est la fin du tableau)
Souvent en C ça fait crasher le programme mais ici à coté il y a de la mémoire allouée pour la suite donc ça ne crashe pas, et ça va juste illégalement lire ce qu'il y a à coté.

4) Souvent dans la mémoire adjacente à argv il y a envp, l'environnement (tableau comme argv avec délimiteur NULL), c'est généralement la façon dont fonctionne l'exécution des programmes sous linux et la plupart des os.

5) Du coup ensuite en 632 il cherche le programme dans le PATH et ligne 639 il assigne s (le binaire trouvé et son path complet) à argv[n] (et donc on assigne la nouvelle de chaine de charactère à l'addresse de la première variable d'environnement)
Chose illégale également (enfin par illégal, ici je parle dans la logique du programme bien évidemment)

Mise en situation :

En gros par exemple avec value en tant que première var d'env (oui je vole honteusement l'exemple de l'article que j'explique)
g_strdup lis value dans l'environnement et va le chercher dans le PATH, ensuite met le chemin complet de value dans l'environnement à nouveau par dessus value et potentiellement un peu de la suite.

Tout ceci ne permet pas directement l'exécution de value, mais l'injection de nouvelles variable d'environnement, j'y reviens après.

Appartée sur les shared librairies et mise en contexte :

Explication rapide de la base des bases des shared libraries.
En gros ce sont des bibliothèques mais au lieu d'être compilées avec et dans le binaire (compiler c'est transformer du code en binaire dans un format exécutable)
Elles sont à l'extérieur dans des fichiers .so sous linux (équivalent des .dll sous windows pour faire simple pour ceux qui connaissent) chargées au runtime.

Il est possible d'overload celles configurées par ldconfig pour être chargées par default via la variable d'environnement LD_PRELOAD (variable qui permet de précharger des librairies avant d'autres).
Sauf que les programmes lancés en setuid normalement ignorent LD_PRELOAD au lancement car c'est un risque assez grand de directement permettre l'exécution de librairies frauduleuses à la place de celles de base.

Retour à l'explication et mise en situation :

Maintenant vous voyez peut-être ou je veux (et l'article aussi) en venir.
En mettant dans le PATH un emplacement valide et un nom d'exécutable valide présent dans le PATH il y a moyen de placer LD_PRELOAD à l'addresse de la première variable d'environnement (espace illégal ligne 639) et donc d'injecter des librairies frauduleuses avec les droits suid.

Cette librairie fabriquée par l'attaquant peut exécuter n'importe quoi en root (vu que l'owner de pkexec est root et qu'il y a le suid) et donc shell, backdoor, etc.....

Patch :
- Temporairement disable le setuid mais c'est pas viable au long terme (car en gros ça sabote son intérêt)
- Mise à jour dans les prochaines semaines
- patch script systemtap vu sur le site de redhat qui empêche pour polkit l'exécution avec 0 arguments

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

        if (cmdline_arg(1) == "")

                        raise(9);

}

- Lien du patch sur les sources officielles déjà pending

Conclusion :

Pour résumer un SUID + une erreur dans le code permettant de l'exécution, ça fait des chocapics ça permet une élévation de privilège à root

N'hésitez pas à poser des questions sur des imprécisions/ambiguïté pour que j'édite mon post pour l'adapter au mieux aux débutants.
Si vous observez une erreur n'hésitez pas à me le remonter.

Aussi c'est un peu dense mais bon j'ai édité, coloré et divisé l'explication pour la rendre plus digeste.
Pour les pressés, bah il y a un TLDR donc pas de lézard.

Pour plus de détails n'hésitez pas à lire le troisième lien de mon post précédent.

Dernière modification par naguam (27-01-2022 15:17:52)

anonyme · 27-01-2022 10:53:59

Bonjour
sur buster la mise a jour de sécurité pour ce souci

apt list --upgradable

En train de lister... Fait

libjavascriptcoregtk-4.0-18/oldstable 2.34.4-1~deb10u1 amd64 [pouvant être mis à jour depuis : 2.34.3-1~deb10u1]

libnss3/oldstable 2:3.42.1-1+deb10u5 amd64 [pouvant être mis à jour depuis : 2:3.42.1-1+deb10u4]

libpolkit-agent-1-0/oldstable 0.105-25+deb10u1 amd64 [pouvant être mis à jour depuis : 0.105-25]

libpolkit-backend-1-0/oldstable 0.105-25+deb10u1 amd64 [pouvant être mis à jour depuis : 0.105-25]

libpolkit-gobject-1-0/oldstable 0.105-25+deb10u1 amd64 [pouvant être mis à jour depuis : 0.105-25]

libwebkit2gtk-4.0-37/oldstable 2.34.4-1~deb10u1 amd64 [pouvant être mis à jour depuis : 2.34.3-1~deb10u1]

policykit-1/oldstable 0.105-25+deb10u1 amd64 [pouvant être mis à jour depuis : 0.105-25]

ps: l'installation de buster très récente , moins d'une semaine

Tawal · 27-01-2022 12:12:56

Hello,

Sur Bullseye, c'était hier pour moi :

Date Début : 2022-01-26  00:41:47

Date Fin   : 2022-01-26  00:43:09

Commande   : apt -y upgrade

Demandeur  : tawal (1000)

Upgradés :

   gir1.2-javascriptcoregtk-4.0:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1)

   gir1.2-polkit-1.0:amd64 (0.105-31, 0.105-31+deb11u1)

   gir1.2-webkit2-4.0:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1)

   libjavascriptcoregtk-4.0-18:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1)

   libnss3:amd64 (2:3.61-1+deb11u1, 2:3.61-1+deb11u2)

   libnss3:i386 (2:3.61-1+deb11u1, 2:3.61-1+deb11u2)

   libpolkit-agent-1-0:amd64 (0.105-31, 0.105-31+deb11u1)

   libpolkit-gobject-1-0:amd64 (0.105-31, 0.105-31+deb11u1)

   libwebkit2gtk-4.0-37:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1)

   policykit-1:amd64 (0.105-31, 0.105-31+deb11u1)

10 paquets upgradés

Debian-facile

#1 26-01-2022 19:45:46

[résolu] faille de sécurité PwnKit

#2 26-01-2022 21:57:00

Re : [résolu] faille de sécurité PwnKit

#3 26-01-2022 22:32:41

Re : [résolu] faille de sécurité PwnKit

#4 27-01-2022 00:05:45

Re : [résolu] faille de sécurité PwnKit

#5 27-01-2022 01:29:27

Re : [résolu] faille de sécurité PwnKit

#6 27-01-2022 01:32:46

Re : [résolu] faille de sécurité PwnKit

#7 27-01-2022 01:41:51

Re : [résolu] faille de sécurité PwnKit

#8 27-01-2022 02:19:42

Re : [résolu] faille de sécurité PwnKit

#9 27-01-2022 10:53:59

Re : [résolu] faille de sécurité PwnKit

#10 27-01-2022 12:12:56

Re : [résolu] faille de sécurité PwnKit

Pied de page des forums