Journal Et ça continue [DirtyFrag]

Posté par  . Licence CC By‑SA.
Étiquettes :
20
7
mai
2026

Après CopyFail, voilà DirtyFrag…https://github.com/V4bel/dirtyfrag

Et encore une fois, il y a eu un raté sur le NDA (sauf que là, le gars dit que ce serait d'une tierce partie).

Par contre, je serais bien incapable de dire si le module impacté est nécessaire ou non à quelque chose une machine standard. Et donc je ne peux pas dire si le workaround est à faire ou non…

  • # Oui quand même

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

    Il y a trois modules listés : esp4, esp6 et rxrpc.

    RxRPC, je ne connais pas, mais ça semble surtout utile pour AndrewFS (AFS), un système de fichier réseau qui est, je crois, assez confidentiel.

    Par contre, ESP, c'est un bout d'IPSec, qui est utilisé dans beaucoup de technos de VPN, donc probablement présent et utile dans énormément de firewalls.

    Pour une machine de "particulier", ça semble sans impact de les désactiver en attendant.

    Vivement un exploit dans le module ipv4 directement qu'on rigole un peu :).

    • [^] # Re: Oui quand même

      Posté par  . Évalué à 4 (+3/-1). Dernière modification le 08 mai 2026 à 07:40.

      Il y a très peu de chance que ces modules soient chargés si IPsec n'est pas utilisé.

      Et si c'est utilisé, le contournement qui consiste décharger ces modules le rendra inopérant.

      Pour vérifier il suffit d'utiliser lsmod (en root)

      Comme pour l'autre PoC, attention aux tests : l'exploit sera actif tant que la mémoire cache n'est pas vidée ou la machine redémarrée.

  • # Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

    Petite question pour éviter de cela : Quelles sont les recommandations pour partager ce type d'info urgente sur LinuxFr? Est-ce Forum/Journal/Lien? (sans doute pas dépêche)
    Je pensais que Journal était plus pour des sujets de fond, n'étant pas une dépêche.

    • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

      Quelles sont les recommandations pour partager ce type d'info urgente sur LinuxFr? Est-ce Forum/Journal/Lien? (sans doute pas dépêche)

      Pour l'instant, je n'ai pas vu de recommandation formelle sur FAQ ni sur le wiki.

      En pratique, je privilégierais le journal pour des infos urgente. Toutefois, il est possible de faire une dépêche urgente, mais il faudra prendre un certain délai avant sa publication, le temps que l'équipe de modération valide le contenu.

      Je pensais que Journal était plus pour des sujets de fond, n'étant pas une dépêche.

      D'après la FAQ, les journaux sont l'équivalent d'un espace de blog à disposition des inscrits. Il n'y a donc pas de contrainte explicite sur le type de contenu à mettre (sauf à ne rien faire d'illicite au regard de la loi française).

    • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

      Posté par  (courriel, site web personnel) . Évalué à 3 (+2/-1).

      Je pense que l'idéal serait que si quelqu'un poste une dépêche avec un titre en majuscules grasses rouges commençant par 👉URGENT👈 cela outrepasse la modération est soit immédiatement posté avec une notification à tous les membres du site via tous les moyens de communications enregistrés (e-mail, XMPP, Mastodon,…).

      Alternativement, les gens que ça intéressent peuvent souscrire aux listes de diffusion adéquates. Par exemple linux-cve-announce ou debian-security-announce.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

        Posté par  (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 08 mai 2026 à 14:49.

        arf, oui bonne proposition de contournement de la modération pour que les bots prennent le contrôle de LinuxFr.org et rendre aux dépêches une de leur signification (à l'impératif :D) ainsi que mobiliser tous les endormis sur LinuxFr.org ne postant ni journaux, ni liens, ni entrées de forums intéressantes   _o/

        moi je vote pour ! Euh, wait… stait de l'humour ? Rassure-moi :p

        • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

          C'est uniquement de l'humour si on considère que LinuxFr n'est pas la bonne plateforme pour diffuser « ce type d'info urgente ».

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

            Posté par  (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 08 mai 2026 à 19:00.

            Pour moi, LinuxFr.org est une bonne plateforme pour diffuser ce type d'info en respectant la divulgation responsable.

            Donc ok pour entamer une dépêche en rédaction et consolider les informations disponibles au fur et à mesure (CVE, disponibilité des correctifs, contournements/palliatifs au pire pour réduire les utilisations possibles…). Une fois que les exploits sont dans la nature, pas besoin d'emballer la machine àmha tant que des correctifs ou palliatifs efficaces « au mieux » (donc pas idéal :/) ne sont pas proposés.

            Après, journaux et forums donnent lieu à modération a posteriori : cela peut être intéressant d'avoir l'avis de l'équipe actuelle de modération sur ce qui aiderait à trancher ;-)

          • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

            Si c'est une bonne plateforme.

            Maintenant, on a le choix :

            • l'info immédiate via les liens par exemple,
            • un peu plus d'info à chaud via les journaux comme ici,
            • des infos un peu moins chaudes via les dépêches avec la description du problème, comment il a été découvert, les risques et les parades.

            Comme ça non seulement l'info est couverte mais en plus on apporte un plus.

            Et évidemment, indiquer que la dépêche est urgente est utile.

            Dans ce cas d'espèce particulier, par exemple, on peut maintenant envisager une dépêche qui indiquerait tout ça, qui est réellement impacté et les correctifs apportés.

            Mon avis personnel c'est que communiquer l'info à chaud c'est important, mais attendre d'en savoir plus c'est essentiel pour une communication plus efficace. Donc les trois leviers que j'ai indiqués se complètent.

            Je n’ai aucun avis sur systemd

            • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

              L'espace de rédaction de dépêches dispose déjà d'un bouton "marquer comme urgent" pour prévenir l'équipe de modération qu'il faut publier rapidement. Ça sera peut-être pas fait dans la minute, mais parfois c'est pas mal de prendre un tout petit peu de recul.

            • [^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal

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

              Si c'est une bonne plateforme.

              Je pense que linuxfr est une bonne plateforme pour discuter de ce genre de choses.

              Je pense que linuxfr est une mauvaise plateforme pour être informé en temps voulu des mitigations et patches de sécurité à appliquer en urgence. Si l'équipe de linuxfr veut changer cela, il y a des évolutions qui peuvent être considérées mais ça ne me semble pas particulièrement pertinent dans le sens où il y a déjà d'autres plateformes qui jouent ce rôle et où ça dérouterait de l'énergie qui serait sans doute mieux investie à maintenir et améliorer le bon fonctionnement de l'aspect discussion.

              Je contribue volontiers à la rédaction d'une dépêche de fond sur les bogues de sécurité en général ou cette série de bogues en particulier si quelqu'un veut se lancer là dedans.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # CVE-2026-43284

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

    Un numéro CVE a été attribué.

    Le suivi pour :

    Le correctif publié pour le noyau.

  • # comme d'habitude ?

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

    On est d'accord que toutes ses failles nécessitent un accès local ?

    Il me semble que, depuis toujours, il faut considérer un accès local sur une machine comme une machine compromise.

    Du coup : c'est intéressant, mais peut-être pas nécessaire de communiquer dessus comme si c'était la fin du monde à chaque fois ?

    • [^] # Re: comme d'habitude ?

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

      Pas forcément compromise, non.
      Exemple : j'administre des machines qui enregistrent des images de vidéosurveillance. Des techniciens ont le droit de se connecter dessus, avec des droits réduits, pour observer les journaux et redémarrer les services. Mais pas installer des nouveaux paquets ou arrêter la machine.

      Ceci étant dit, le fait que ça nécessite un accès local réduit fortement la sévérité, en effet.

      • [^] # Re: comme d'habitude ?

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

        Après, beaucoup de failles qui nécessitent un accès local ne nécessitent en vrai "que" un RCE. Des RCE pour wordpress par exemple il y en a régulièrement. D'autant plus que copy.fail était vraiment très facile à exploiter (celle-ci je n'ai pas testé)

    • [^] # Re: comme d'habitude ?

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

      La fin du monde, ça dépend pour qui. Je suis assez tranquille pour mes serveurs, je suis le seul utilisateur dessus : ça m'ennuie mais j'ai suffisamment d'espoir que personne d'autre ne puisse venir exécuter du code dessus.

      En revanche, pour les machines accessibles aux élèves en salles de TP au boulot, j'espère vraiment voir un nouveau noyau dans le week-end.

      • [^] # Re: comme d'habitude ?

        Posté par  . Évalué à 4 (+3/-1). Dernière modification le 08 mai 2026 à 12:43.

        je suis le seul utilisateur dessus

        Vraiment ?
        Pas d'utilisateurs système et tu es root ?
        Voir le commentaire de @nud ci-dessus sur ce qui peut se passer avec une faille dans un CMS par exemple. Si la faille permet d'obtenir un shell utilisateur (celui défini pour exécuter les scripts PHP dan le cas du Wordpress), les exploits comme copy.fail sont utilisables.

    • [^] # Re: comme d'habitude ?

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

      On est d'accord que toutes ses failles nécessitent un accès local ?

      Comme déjà évoqué dans d'autres commentaires, il faut se méfier de ce qu'on entend par "accès local".
      Car d'une certaine façon, une application PHP qui aurait été détournée peut être considérée comme ayant un accès local si, par exemple, elle a des tâches cron associées.

    • [^] # Re: comme d'habitude ?

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

      Attention, accès local ne veut pas dire un compte avec un shell et un mot de passe et qu'on se connecte en SSH. Ça peut vouloir dire aussi un démon non privilégié mais bogué (comme Apache cette semaine ou comme certainement beaucoup de scripts PHP).

      • [^] # Re: comme d'habitude ?

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

        Si par "Apache cette semaine", tu parles de la faille CVE-2026-23918, je pense qu'il est important de pointer que la faille a été corrigé en décembre 2025. Ça devait pas être si urgent ou si troué si il a fallu attendre mai pour l'avoir en version stable.

        Que je sache, il n'y a pas d'exploit qui circule, et le seul article que j'ai trouvé est écrit par une IA générative et semble dire de la merde (genre, ç'est exploitable si tu peux appeler mmap, donc en gros, tu peux exécuter du code arbitraire si tu es capable d’exécuter du code arbitraire).

    • [^] # Re: comme d'habitude ?

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

      Quand on évalue une faille de sécurité, il y a plusieurs critères à considérer: facilité de mise en oeuvre, pré-requis (comme avoir déjà la possibilité d'exécuter du code non privilégié), conséquences, …

      Celles-ci sont d'un niveau assez haut pour certains de ces critères, et surtout elles ont été publiées très vite, alors que le processus recommandé est de d'abord prévenir les équipes de Linux ainsi que des principales distributions, de sorte que la faille soit publiée après le déploiement du correctif. Ça n'a pas été fait dans les règles, peut-être parce que les entreprises ayant découvert ces failles cherchent à faire un maximum de bruit pour se faire de la publicité.

      Cela explique la panique autour de ces problèmes. Pour l'évaluation de faille, une bonne partie est à faire en fonction du contexte: c'est assez différent entre un PC personnel, un système embarqué sur lequel il n'y a pas du tout de shell, un serveur mutualisé d'hébergement web qui fournit des accès ssh à tout le monde, … À vous de finir cette évaluation dans votre contexte pour déterminer à quel niveau d'urgence il faut traiter l'installation des correctifs.

      • [^] # Re: comme d'habitude ?

        Posté par  (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 08 mai 2026 à 21:40.

        Ça n'a pas été fait dans les règles

        effectivement

        peut-être parce que les entreprises ayant découvert ces failles cherchent à faire un maximum de bruit pour se faire de la publicité.

        pour Dirty Frag on peut laisser le bénéfice du doute suite à https://www.openwall.com/lists/oss-security/2026/05/07/12 vu en lien de https://lwn.net/Articles/1071775/

        I had no contact with anyone on the linux-distros embargo, no awareness
        of the May 12 disclosure date, and no access to Kim's write-up or PoC.

        le gars se base sur une CVE et ne se coordonne avec personne, m'enfin bon :/

        Concernant la dénomination de faille « locale », ça se contourne facilement et peut toucher tout utilisateur fervent adepte du curl http://pourleszozos.example.com | sh (bref, toute ICC1 défaillante) ou une faille éventuelle de chromium / firefox permettant d'exécuter du code…

        1. ICC ou Interface Chaise-Clavier, le principal maillon faible ;-) ↩

    • [^] # Re: comme d'habitude ?

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

      Il me semble que, depuis toujours, il faut considérer un accès local sur une machine comme une machine compromise.

      Ça n’est pas pour autant qu’il faut considérer que la sécurité en question n’est pas importante. D’une part parce que les dommages d’un attaquant qui ouvre un shell fortement limité sur ta machine et d’un attaquant qui ouvre un shell root ne sont pas les même. Même si tu considère les 2 machines comme compromises les dégâts ne sont pas les même. D’autre part car il y a des fois où tu dois laisser des portes ouvertes et t’appuyer sur des sécurités en profondeur pour ton travail. Un administrateur de réseaux de machine au collège ne souhaite pas que les collégiens puissent obtenir les droits root, mais il ne va pas considérer chaque machine ou l’un de s’est connecté comme compromise non plus.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # De l'impossibilité d'une divulgation coordonnée

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

    Et encore une fois, il y a eu un raté sur le NDA (sauf que là, le gars dit que ce serait d'une tierce partie).

    On trouve une info plus précise via ce témoignage sur la liste mail oss-security de _SiCk qui a développé un exploit sur la base de :
    - un commit (public) corrigeant une partie de la faille
    - un message sur un réseau social d'un analyste sécurité devinant, derrière ce commit, la présence d'une faille

    Ça démontre qu'aujourd'hui on va très rapidement avoir un code d'exploitation dès qu'un commit corrigeant une faille est publié (même sans mention explicite de vulnérabilité dans la description du commit). Plusieurs objectifs sont donc incompatibles :
    - travailler en public
    - avoir des délais entre l'écriture d'un correctif et son application (délai entre écriture et merge liés au process de review, délai entre merge upstream et packaging downstream)
    - protéger les systèmes downstream des failles n-days pour n inférieur aux délais ci-dessus

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.