Faille locale dans les fonctions pipe_*_open() du noyau Linux

Posté par  (site web personnel) . Modéré par rootix.
38
5
nov.
2009
Sécurité
Une situation de compétition (race condition) a été trouvée le 14 octobre dans les fonctions pipe_read_open(), pipe_write_open() et pipe_rdwr_open() du noyau Linux par Earl Chew, bug vieux de plus de dix ans. Deux jours plus tard, Earl a écrit un patch corrigeant le bug (commité le 21 octobre, il fait partie de la version 2.6.32-rc6).

L'histoire pourrait s'arrêter là, mais Eugene Teo de Red Hat a découvert cinq jours plus tard que le bug est une faille de sécurité. La faille est facile à exploiter avec la boîte à outils de Brad Spengler. Comme les dernières failles du noyau Linux (vmsplice(), tun_chr_pool() et perf_counter), la faille est liée au déréférencement d'un pointeur NULL. Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. Il devrait publier son exploit dans les prochains jours.

Pour se protéger (ou vérifier si votre système est vulnérable ou non), assurez-vous que la valeur de /proc/sys/vm/mmap_min_addr ne soit pas nulle. Debian Sid, Mandriva Linux 2010.0, Fedora 12, Ubuntu (Ibex et supérieurs) et les noyaux patchés avec grsecurity ne sont pas vulnérables. Alors que Debian Lenny et Squeeze ont une valeur nulle par exemple (il est prévu de changer ça à partir de Debian 5.0.4). Comme l'option mmap_min_addr a été introduite dans Linux 2.6.23, Debian Etch (qui utilise un noyau 2.6.18) est vulnérable : vous pouvez utiliser les paquets etchhalf pour installer un noyau 2.6.24. Des correctifs pour RedHat sont déjà disponibles. Les fonctions pipe_read_open(), pipe_write_open() et pipe_rdwr_open() ont été introduites dans la version 1.3.44 du noyau Linux (novembre 1995). Un verrou a été ajouté dans la version 2.3.15 (août 1999). Sa découverte est sûrement due à la popularisation des processeurs multi-cœurs (exécution de plusieurs processus réellement parallèle, augmentant la probabilité des situations de compétition), et on peut craindre que d'autres bugs similaires soient découverts (bugs difficiles à identifier manuellement et à reproduire). Consultez l'article CVE-2009-3547: Linux kernel Pipe NULL Pointer Dereference Race Condition pour des explications sur la faille.

Une des raisons pour laquelle /proc/sys/vm/mmap_min_addr est toujours nul sur certaines distributions Linux est que cela pose problème avec quelques applications comme Qemu (pouvoir exécuter Qemu en tant qu'utilisateur non root, limitation supprimée dans les versions récentes), Wine ou DOSEMU.

Notons que la classe de bug « déréférencement de pointeur NULL » n'est pas spécifique à Linux, FreeBSD en est aussi victime par exemple. Pour preuve, ce bug récent découvert dans devfs : FreeBSD-SA-09:14 (lire Devfs/VFS NULL Pointer Race Condition pour les explications). Il existe une protection pour FreeBSD interdisant d'allouer une page mémoire à l'adresse NULL : FreeBSD-EN-09:05. Elle est activée par défaut sous FreeBSD 8, mais doit être activée manuellement sur les versions plus anciennes (ajoutez la ligne « security.bsd.map_at_zero="0" » dans /etc/sysctl.conf).

Aller plus loin

  • # Rien à voir mais

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

    Au lieu de Eugene Teo de Red Hat, j'ai lu Eugene Theo De Raadt et j'ai failli m'étouffer en croyant apprendre que le responsable du projet OpenBSD était passé passé sous Linux...
    • [^] # Re: Rien à voir mais

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

      J'ai fait la même erreur... :D
      • [^] # Re: Rien à voir mais

        Posté par  . Évalué à 10.

        C'est une erreur d'autant plus savoureuse quand on connait la réaction du Theo de Raadt sur la question: http://article.gmane.org/gmane.os.openbsd.misc/164894

        Ça me rappelle que vendredi s'approche, tiens. En même temps, pour Theo, c'est un peu vendredi tous les jours.
        • [^] # Re: Rien à voir mais

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

          Le commit OpenBSD date de juin 2008, alors que Linux possédait déjà l'option mmap_min_addr depuis octobre 2007 (noyau 2.6.23). Mais il est vrai que la valeur par défaut ne protège pas des exploits noyau (c'est à la distribution de bien configurer Linux, choix discutable, alors qu'OpenBSD décide pour l'utilisateur).

          The #1 reason why the Linux team has not commited this by default is because it breaks Wine

          Petite précision pour Wine : seule l'exécution de programme Win16 (Windows 3.1 ?) dans Wine pose problème avec mmap_min_addr. Mais il n'y a pas que Wine qui est impacté par mmap_min_addr : dosemu, qemu et BitBake le sont également. Oui, qemu peut servir à émuler un système d'exploitation propriétaire, mais il est beaucoup utilisé pour tester (voir même utiliser !) Linux. kvm est d'ailleurs basé dessus. Il me semble que certains utilisent même qemu pour exécuter Linux sous Windows (mais là c'est hors sujet) :-)

          Je pense également que SELinux et grsecurity protègent des bugs « déréférencement de pointeur NULL » depuis fort longtemps (ex: option « UDEREF » de PaX), mais j'ai la flemme de chercher une date.
          • [^] # Re: Rien à voir mais

            Posté par  . Évalué à 1.

            > Je pense également que SELinux et grsecurity protègent des bugs « déréférencement de pointeur NULL » depuis fort longtemps

            Au contraire, il me semble que les premiers exploit « déréférencement de pointeur NULL » avaient besoin de SELinux our fonctionner.
            En gros, sur redhat (ou fedora, sais plus), SELinux positionnait cette fameuse mmap_min_addr à zéro, alors que par défaut dans linux ce n'était pas le cas.

            A moins que je ne mélange avec autre chose.
        • [^] # Re: Rien à voir mais

          Posté par  . Évalué à 1.

          Merci pour le lien. Très amusant à lire et à suivre cette guerre d'ego entre les 2 personnages :-)
        • [^] # Re: Rien à voir mais

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

          Sa réaction n'est pas drôle : c'est Linus qui a commencé :)
  • # encore et toujours la meme faille (ou presque)

    Posté par  . Évalué à 2.

    cela se corrige en mettant une valeur differente de zero dans /proc/sys/vm/mmap_min_addr

    la question qui reste etant de savoir si ce mmap_min_addr est un patch pour corriger une faille du noyau

    ou une fonctionnalité de securité non utilisée par certaines distribs pour mettre de faire fonctionner des logiciels comme Wine (il parait que Wine ne fonctionne plus si mmap_min_dir n'est pas 0 )
    • [^] # Re: encore et toujours la meme faille (ou presque)

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

      Tiens, en lisant http://lwn.net/Articles/347390/ j'ai trouvé la justification de RedHat sur le fait que mmap_min_addr soit toujours nul : « In RHEL5 the boolean is enabled by default for backwards compatibilitally, as mmap_min_addr was introduced during the lifetime of RHEL5, allowing all unconfined domains to mmap_zero. (...) We are not planning on changing the default in RHEL5, to maintain backawards compatability. »
      http://danwalsh.livejournal.com/30084.html

      Pour Debian Stable, je pense que la raison est la même. Pour Debian Testing par contre, il me semble que mmap_min_addr soit toujours nul, mais j'espère que ça sera changé (c'est prévu pour Debian 5.04 en tout cas).
  • # Vérification à faire avec Ubuntu

    Posté par  . Évalué à 2.

    Le dépêche affirme que Ubuntu karmic n'est pas vulnérable. Or sur l'un de mes systèmes j'observe ceci:

    $ cat /proc/sys/vm/mmap_min_addr
    0

    et sur un autre l'observe ceci:

    $ cat /proc/sys/vm/mmap_min_addr
    65536

    Je ne sais pas encore d'où vient la différence, mais en tout cas, j'encourage tous les utilisateurs d'Ubuntu à vérifier eux mêmes.
  • # Mais wine marche !

    Posté par  . Évalué à 1.

    $ cat /proc/sys/vm/mmap_min_addr # Valeur non nulle par défaut (gentoo)
    4096

    $ wine notepad # wine-1.1.27 fonctionne...
    • [^] # Re: Mais wine marche !

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

      Extrait du 2e lien (wiki Debian) : « wine
      Only Win16 binaries require the ability to mmap low addresses, Win32 binaries do not. It is recommended that you test your application with the increase mmap_min_addr setting. If the application starts up without issue, then you should not need to remove the mmap_min_addr restriction.
      »
      • [^] # Re: Mais wine marche !

        Posté par  . Évalué à 3.

        C'est faux, j'ai pris un vieux jeux win16 (il y en a plein sur les sites abandonware) et ca marche.

        Le seul pb, c'est pour les jeux dos utilisant vm86 et des jeux qui font des trucs un peu louche.

        Du coup on se demande pourquoi autant de machine n'ont pas un mmap_min_addr non null...
  • # Inverse de Ubuntu

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

    Comme Laurent Bonnaud nous le fait remarquer pour Ubuntu, j'ai vérifié sur ma Fedora 11.

    Fedora 11 non mise à jour (si !) depuis aout.
    La valeur de /proc/sys/vm/mmap_min_addr est non nulle (65536 ici,...)
    -> Selinux est activé en mode enforcing. Avec config, et pour un repertoire, à la racine, non standart : /local

    Je ne dirai pas que la dépêche se trompe, loi de là :-) (au passage merci Victor pour cette dépêche : concise, précise, complète et agréable), simplement un message pour les autres utilisateurs de Fedora 10 et 11 : vérifiez... chez moi, une F11 non mise à jour, le bug n'existe pas.
    • [^] # Re: Inverse de Ubuntu

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

      Wine est installé également : wine-core-1.1.29-1.fc11.i586 et sa suite (desktop, jack, twain...) Cette faille est exploitable à cause d'un packaging de wine ?
      Donc encore une fois, la qualité Fedora, c'est quelque chose, quant même :-)
      • [^] # Re: Inverse de Ubuntu

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

        Sur Fedora 11, si on écrit 0 dans mmap_min_addr, l'exploit fonctionne, arrive à contourner SELinux (et aucun avertissement SELinux n'est affiché). En plus, il affiche une image se moquant du modèle de sécurité de SELinux (Discretionary access control vs Mandatory Access Control).
        • [^] # Re: Inverse de Ubuntu

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

          Il faut donc pouvoir être root au préalable, pour pouvoir remplacer la valeur de la mmap_min_addr, et la placé à zéro. Et ensuite on peux s'amuser avec le nouvel exploit de Brad ?

          "hé les gars, j'ai un nouvel exploit pour passer root sous linux : bon d'abord vous devez être root..."
    • [^] # Re: Inverse de Ubuntu

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

      Au sujet de ma phrase « Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. », j'ai utilisé les captures d'écran publiées par Brad (j'ai utilisé le peu d'infos disponibles sur le net). Pour Fedora 11 par exemple : http://grsecurity.net/~spender/fc11.png (mise en ligne le 3 novembre). Peut-être que cette capture d'écran n'est pas liée à l'exploit MooseCox (pipe) ou que c'est une Fedora 11 pas à jour.

      Je viens de tester l'exploit sous une Fedora 11 à jour, et 1) l'exploit ne fonctionne 2) beaucoup mieux : SELinux affiche un avertissement comme quoi il y a eu une attaque. Bravo Fedora ! Bravo SELinux ! clap clap clap !
      http://www.haypocalc.com/tmp/fedora_enlightenment.png
  • # Brad a publié son exploit

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

    Vous ne pouvez plus ignorer la faille maintenant que l'exploit est public : http://grsecurity.net/~spender/enlightenment.tgz

    Lancez "./run_null_exploit.sh", c'est l'exploit « MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root ». L'exploit ne fonctionne pas sur Ubuntu (car mmap_min_addr est non nul), mais fonctionne très bien sur Debian Lenny. J'espère que Debian va se bouger les fesses.
    • [^] # Re: Brad a publié son exploit

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

      Avec des noms d'exploit comme ça on a pas fini de troller sur enlightenment ...
    • [^] # Re: Brad a publié son exploit

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

      Suer une Fedora 12 (rawhide pour le moment) à jour de ce matin:


      ./run_null_exploits.sh
      Compiling exp_cheddarbay.c...OK.
      Compiling exp_ingom0wnar.c...OK.
      Compiling exp_moosecox.c...OK.
      Compiling exp_paokara.c...OK.
      Compiling exp_powerglove.c...OK.
      Compiling exp_therebel.c...OK.
      Compiling exp_vmware.c...OK.
      Compiling exp_wunderbar.c...OK.
      [+] Personality set to: PER_SVR4
      Pulseaudio is not suid root!

      ./run_nonnull_exploits.sh
      Compiling exp_cheddarbay.c...OK.
      Compiling exp_ingom0wnar.c...OK.
      Compiling exp_moosecox.c...OK.
      Compiling exp_paokara.c...OK.
      Compiling exp_powerglove.c...OK.
      Compiling exp_therebel.c...OK.
      Compiling exp_vmware.c...OK.
      Compiling exp_wunderbar.c...OK.
      Choose your exploit:
      [0] Ingo m0wnar: Linux 2.6.31 perf_counter local root (Ingo backdoor method)
      [1] Exit
      > 0
      ------------------------------------------------------------------------------
      Before the Law stands a doorkeeper. To this doorkeeper there comes a man
      from the country who begs for admittance to the Law. But the doorkeeper
      says that he cannot admit the man at the moment. The man, on reflection,
      asks if he will be allowed, then, to enter later. 'It is possible,' answers
      the doorkeeper, 'but not at this moment.' Since the door leading into the
      Law stands open as usual and the doorkeeper steps to one side, the man bends
      down to peer through the entrance. When the doorkeeper sees that, he laughs
      and says: 'If you are so strongly tempted, try to get in without my
      permission. But note that I am powerful. And I am only the lowest
      doorkeeper. From hall to hall, keepers stand at every door, one more
      powerful than the other. And the sight of the third man is already more
      than even I can stand.' These are difficulties which the man from the
      country has not expected to meet, the Law, he thinks, should be accessible
      to every man and at all times, but when he looks more closely at the
      doorkeeper in his furred robe, with his huge, pointed nose and long, thin,
      Tartar beard, he decides that he had better wait until he gets permission to
      enter. The doorkeeper gives him a stool and lets him sit down at the side
      of the door. There he sits waiting for days and years. He makes many
      attempts to be allowed in and wearies the doorkeeper with his importunity.
      The doorkeeper often engages him in brief conversation, asking him about his
      home and about other matters, but the questions are put quite impersonally,
      as great men put questions, and always conclude with the statement that the
      man cannot be allowed to enter yet. The man, who has equipped himself with
      many things for his journey, parts with all he has, however valuable, in the
      hope of bribing the doorkeeper. The doorkeeper accepts it all, saying,
      however, as he takes each gift: 'I take this only to keep you from feeling
      that you have left something undone.' During all these long years the man
      watches the doorkeeper almost incessantly. He forgets about the other
      doorkeepers, and this one seems to him the only barrier between himself and
      the Law. In the first years he curses his evil fate aloud; later, as he
      grows old, he only mutters to himself. He grows childish, and since in his
      prolonged study of the doorkeeper he has learned to know even the fleas in
      his fur collar, he begs the very fleas to help him and to persuade the
      doorkeeper to change his mind. Finally his eyes grow dim and he does not
      know whether the world is really darkening around him or whether his eyes
      are only deceiving him. But in the darkness he can now perceive a radiance
      that streams inextinguishably from the door of the Law. Now his life is
      drawing to a close. Before he dies, all that he has experienced during the
      whole time of his sojourn condenses in his mind into one question, which he
      has never yet put to the doorkeeper. He beckons the doorkeeper, since he
      can no longer raise his stiffening body. The doorkeeper has to bend far
      down to hear him, for the difference in size between them has increased very
      much to the man's disadvantage. 'What do you want to know now?' asks the
      doorkeeper, 'you are insatiable.' 'Everyone strives to attain the Law,'
      answers the man, 'how does it come about, then, that in all these years no
      one has come seeking admittance but me?' The doorkeeper perceives that the
      man is nearing his end and his hearing is failing, so he bellows in his ear:
      'No one but you could gain admittance through this door, since this door was
      intended for you. I am now going to shut it.' --Kafka
      ------------------------------------------------------------------------------
      [+] Resolved ima_audit to 0xc0acd58c
      [+] Resolved ima_file_mmap to 0xc057da68
      [+] Resolved ima_bprm_check to 0xc057da8d
      [+] Resolved ima_path_check to 0xc057d742
      [+] Resolved selinux_enforcing to 0xc0acb1f8
      [+] Resolved selinux_enabled to 0xc097232c
      [+] Resolved security_ops to 0xc0aca1cc
      [+] Resolved default_security_ops to 0xc0971e4c
      [+] Resolved sel_read_enforce to 0xc05714a3
      [+] Resolved audit_enabled to 0xc0a6e46c
      [+] Resolved commit_creds to 0xc0455765
      [+] Resolved prepare_kernel_cred to 0xc04555c6
      System is not vulnerable.
      • [^] # Re: Brad a publié son exploit

        Posté par  . Évalué à 1.

        il suffit de trouver un autre exec que pulseaudio...
        • [^] # Re: Brad a publié son exploit

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

          En passant, SELinux est désactivé et cat /proc/sys/vm/mmap_min_addr affiche 4096

          Maintenant si


          $ sudo sh -c 'echo 0 > /proc/sys/vm/mmap_min_addr'
          $ cat /proc/sys/vm/mmap_min_addr
          0


          Et l'exploit fonctionne, avec un joli message qui moque SELinux, et j'ai un shell root.


          $ ./run_null_exploits.sh
          Compiling exp_cheddarbay.c...OK.
          Compiling exp_ingom0wnar.c...OK.
          Compiling exp_moosecox.c...OK.
          Compiling exp_paokara.c...OK.
          Compiling exp_powerglove.c...OK.
          Compiling exp_therebel.c...OK.
          Compiling exp_vmware.c...OK.
          Compiling exp_wunderbar.c...OK.
          [+] MAPPED ZERO PAGE!
          Choose your exploit:
          [0] Cheddar Bay: Linux 2.6.30/2.6.30.1 /dev/net/tun local root
          [1] MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root
          [2] Paokara: Linux 2.6.19->2.6.31.1 eCryptfs local root
          [3] Powerglove: Linux 2.6.31 perf_counter local root
          [4] The Rebel: Linux < 2.6.19 udp_sendmsg() local root
          [5] CVE-2009-2267: VMWare vm86 guest local root
          [6] Wunderbar Emporium: Linux 2.X sendpage() local root
          [7] Exit
          > 1
          ------------------------------------------------------------------------------
          With people of limited ability modesty is merely honesty. But with those
          who possess real talent it is hypocrisy. --Schopenhauer
          ------------------------------------------------------------------------------
          [+] Resolved ima_audit to 0xc0acd58c
          [+] Resolved ima_file_mmap to 0xc057da68
          [+] Resolved ima_bprm_check to 0xc057da8d
          [+] Resolved ima_path_check to 0xc057d742
          [+] Resolved selinux_enforcing to 0xc0acb1f8
          [+] Resolved selinux_enabled to 0xc097232c
          [+] Resolved security_ops to 0xc0aca1cc
          [+] Resolved default_security_ops to 0xc0971e4c
          [+] Resolved sel_read_enforce to 0xc05714a3
          [+] Resolved audit_enabled to 0xc0a6e46c
          [+] Resolved commit_creds to 0xc0455765
          [+] Resolved prepare_kernel_cred to 0xc04555c6
          [+] Using newer pipe_inode_info layout
          [+] We'll let this go for a while if needed...
          [+] got ring0!
          [+] detected cred support
          [+] Disabled security of : nothing, what an insecure machine!
          [+] Got root!
          ...
          (GConf errors)
          ...
          sh-4.0# id
          uid=0(root) gid=0(root)
          sh-4.0# exit


          Et je ne pense pas que PulseAudio ait grand chose a voir avec cet exploit, il me semble qu'il s'agit d'autre chose.

          Maintenant:
          $ sudo sh -c 'echo 4096 > /proc/sys/vm/mmap_min_addr'
          • [^] # Re: Brad a publié son exploit

            Posté par  . Évalué à 2.

            Est-ce qu'on peut faire l'inverse ?

            sudo sh -c 'echo 4096 > /proc/sys/vm/mmap_min_addr'

            Et hop la machine est protégée (on peut le mettre dans un script de démarrage).
            • [^] # Re: Brad a publié son exploit

              Posté par  . Évalué à 4.

              c'est mieux avec sysctl:
              echo "vm.mmap_min_addr=4096>>/etc/sysctl.conf" && sysctl -p # le sysctl -p est refait à chaque démarrage.
              ou via /etc/sysctl.d/.
      • [^] # Re: Brad a publié son exploit

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

        uname -a:

        Linux kylae 2.6.31.5-96.fc12.i686.PAE #1 SMP Fri Oct 23 19:39:36 EDT 2009 i686 i686 i386 GNU/Linux
    • [^] # Debian : ça, c'est fait

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

      L'équipe de sécurité Debian vient de publier une nouvelle version du noyau, je crois.

      linux-2.6 (2.6.26-19lenny2) stable-security; urgency=high

      * tc: Fix uninitialized kernel memory leak (CVE-2009-3228)
      * random: make get_random_int() more random (CVE-2009-3238)
      * netlink: fix typo in initialization (CVE-2009-3612)
      * drm/r128: Add test for initialisation to all ioctls that require it
      (CVE-2009-3620)
      * AF_UNIX: Fix deadlock on connecting to shutdown socket (CVE-2009-3621)
      * fs: pipe.c null pointer dereference (CVE-2009-3547)
      * KVM: Prevent overflow in KVM_GET_SUPPORTED_CPUID (CVE-2009-3638)
      • [^] # DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities

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

        CVE-2009-3547

        Earl Chew discovered a NULL pointer dereference issue in the
        pipe_rdwr_open function which can be used by local users to gain
        elevated privileges.

        http://lists.debian.org/debian-security-announce/2009/msg002(...)

        Le noyau ne corrige que la faille pipe. Par contre, mmap_min_addr est inchangé. Ça ne sera changé que dans Debian 5.0.4.
        • [^] # Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities

          Posté par  . Évalué à 2.

          Petite précision : dans Lenny, cela n'est vrai que pour les images de noyau précompilées fournies par Debian (actuellement 2.6.26+17+lenny1).

          Ceux qui, comme moi, compilent leurs propres version locales à partir des sources patchées par Debian, se seront peut-être rendu compte que la valeur mmap_min_addr est initialisé par défaut à 4096 depuis linux-source-2.6.26-19lenny1.

          Cette fois, même les mauvaises langues ne pourront pas dire que compiler le noyau c'est inutile/dépassé/etc. :-p

          THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

          • [^] # Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities

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

            Euh, un simple dist-upgrade t'aurait installé le nouveau noyau précompilé. C'est l'objet du dernier bulletin de sécurité Debian :
            http://www.debian.org/security/2009/dsa-1927

            « For the stable distribution (lenny), this problem has been fixed in version 2.6.26-19lenny2. »

            Tu es tombé au moment où les sources du nouveau noyau étaient en ligne, mais pas encore les paquets binaires (le temps qu'ils soient compilés, puis copiés sur tous les miroirs).
            • [^] # Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities

              Posté par  . Évalué à 2.

              Oui mais non.

              D'abord, je n'utilise pas, en temps normal, les noyaux précompilés par Debian ; ensuite, comme je le précisais dans mon commentaire précédent, la faille a été fixée depuis la publication des sources patchées en 2.6.26-19lenny1.

              Soit, d'après le changelog Debian:

              linux-2.6 (2.6.26-19lenny1) stable-security; urgency=high

              [...]
              * selinux: prevent local users from bypassing mmap_min_addr
              in unconfined domains (CVE-2009-2695)
              [...]

              -- dann frazier <dannf@debian.org> Sat, 17 Oct 2009 10:52:13 -0600


              En vue de corriger le problème ci-dessus, la valeur mmap_min_addr a depuis été fixée à 4096 par défaut. En d'autres termes, cela implique que les personnes ayant compilé leur propre noyau à partir de cette version des sources (depuis le 20 octobre environ) ne sont pas impactés par la présente faille, même s'ils n'ont pas mis à jour leur système récemment ; voilà.

              THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

    • [^] # Re: Brad a publié son exploit

      Posté par  . Évalué à 2.

      La parade pour Debian est sur le wiki : [http://wiki.debian.org/mmap_min_addr]

      En résumé :

      # echo "vm.mmap_min_addr = 4096" > /etc/sysctl.d/mmap_min_addr.conf
      # /etc/init.d/procps restart
  • # Les pauvres qui ont un blob binaire (genre Nvidia)

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

    il fait partie de la version 2.6.32-rc6

    Vu que pour les anciennes cartes il n'existe pas de drivers pour ces noyaux, et que pour les cartes plus récentes il faut attendre (pour le moment, c'est bloqué à 2.6.29), cela démontre encore une fois que l'utilisation de drivers fermés est un problème.

    Sinon, dans le cas d'un serveur virtuel (sans X11) sous OpenVZ, comment ça se passe, vu qu'il n'y a pas de root dans ces machines virtuelles?

    A bientôt
    Grégoire

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Les pauvres qui ont un blob binaire (genre Nvidia)

      Posté par  . Évalué à -10.

      Et moi je plains les pauvres qui utilisent des drivers open source fini au pipi qui ont la bonté de planter le système pile au moment ou il faut pas ...
      • [^] # Re: Les pauvres qui ont un blob binaire (genre Nvidia)

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

        Dieu merci, il y a pas tant de gens qui arrivent à finir des drivers avec leur urine, et donc tu ne doit pas plaindre grande monde, car pour la plupart des pilotes libres, ils sont fini avec un éditeur de texte et de gcc ( sauf Jean Alesi ).

        Au passage, tu semble affirmer qu'il y a des moment ou il ne faut pas planter. Est ce que tu veux dire qu'il y a des moments ou il faut planter ?
  • # Rien sous ArchLinux ?

    Posté par  . Évalué à 1.

    Chez moi, avec Wine d'installé, /proc/sys/vm/mmap_min_addr contient 4096... Pas de problème pour les utilisateurs d'Arch donc ;).
  • # Debian Squeeze pas touché

    Posté par  . Évalué à 4.

    contrairement à ce que dit la dépêche Debian Squeeze n'est pas touché. Il y a 4096 dans mmap_min_dir.
  • # Exploitabilité *réelle*

    Posté par  . Évalué à 1.

    J'ai un peu du mal à capter la dangerosité de la faille. En particulier du fait que le bug permette une escalade de droits à partir d'un compte utilisateur normal.

    Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..

    Pour finir, je rejoins totalement la position de Linus dans ce message:
    http://article.gmane.org/gmane.linux.kernel/706950

    one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.

    It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.

    In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking.
    • [^] # Re: Exploitabilité *réelle*

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

      l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas

      Et bien justement, vu le nombre d'"admins" qui ne suivent pas les failles des softs utilisés en production dans leur parc et se contentent d'appliquer les mises à jours quand elles sont dispo (et encore certains ne font même pas ça), la faille a des chances d'être exploitée tant que le noyau et les distribs ne sont pas patchés, via un exploit sur un soft tiers ne donnant à la base accès qu'à un compte non root.
    • [^] # Re: Exploitabilité *réelle*

      Posté par  . Évalué à 6.

      J'ai un peu du mal à capter la dangerosité de la faille. En particulier du fait que le bug permette une escalade de droits à partir d'un compte utilisateur normal.

      Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..


      Ben je vais te donner un exemple tout con qui m'est réellement arrivé.

      J'avais un PC de bureau, sous Debian. Il ne servait rien sur Internet, n'était utilisable physiquement que par des gens de confiance et des noobs. J'avais créé dessus un compte "invite" avec comme mot de passe "invite", pour les gens de passage.

      Et puis je déménage, je prends une connexion @Internet. Ah, zut, je n'ai pas de serveur sous la main (j'aime bien avoir un serveur chez moi). Bon ben pas grave, je récupère mon vieux Desktop, c'est cool il a deux cartes réseau, j'en fais une passerelle, avec NAT, iptables et tout ça. Je configure iptables comme il faut, en laissant juste le port 22 ouvert (en fait je laisse un screen + irssi dedans, c'est ma principale utilisation pour l'instant d'un "serveur").

      Bon, certes, je n'ai pas viré le compte "invite/invite", mais je fais toujours gaffe à avoir un mot de passe, et perso, et root, qui soient solides, question de principe. Bon.

      Ben ce qui devait arriver m'est arrivé: bruteforce, et quelqu'un est entré sur le compte "invite".
      Tu me diras, "ouais ben j'avais qu'à pas faire de la merde", et j'admets avoir fait de la merde. Je le dis tout haut: J'ai merdé!

      Bon, pour la petite histoire, le gars n'a pas réussi à passer root: coup de bol, je n'utilise pas pulseaudio, et ça date d'avant la publication de cette faille (à quelques jours prêts, j'ai eu chaud).

      Ceci dit, un OS sur lequel n'importe quel utilisateur lambda peut passer root, ben heu..
      Moralité: je vais passer mes serveurs à BSD, _et_ apprendre à administrer correctement mes machines. Deux sécurités valent mieux que zéro.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Exploitabilité *réelle*

        Posté par  . Évalué à -2.

        Merci pour l'histoire :-)

        Ceci dit, sans nier que cela ait pu t'embêter, les failles dites de sécurité sont prétendument critiques à cause des risques majeurs, entendre financiers, qu'elle peuvent faire courir.

        On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.

        Ici, je ne vois pas vraiment en quoi la faille est si problématique. D'ailleurs, en rêgle générale, les failles d'escalade de droits à partir d'un compte local me semblent toujours des failles secondaires, les principales étant celles qui permettent d'avoir un shell à partir d'une application distante...

        Tout ça pour dire que le rush style « ouah encore une faille dans linux » et les « héros » de la sécurité style Brad Spengler, perso j'adhère pas, et je me sens plus proche de ce que dit Linus sur le sujet...
        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 4.

          On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.

          Ben, tu m'excuseras, mais si sur le serveur qui gère les numéros de carte bleues, y'a un technicien, ou un développeur, qui a un compte, et qu'il y a une faille qui permet de passer root, il peut effectivement "voler des centaines de cartes bleues". S'il y a une séparation des droits sur un OS c'est pas pour rien, et ce n'est pas juste pour empêcher qu'une fausse manip ne casse tout.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Exploitabilité *réelle*

            Posté par  . Évalué à -1.

            Mouais... D'expérience, les faille qui permettent de passer root n'ont souvent rien à voir là dedans. De base le technicien ou le développeur a accès à la base de données client en clair, et on parle plus d'un employé mal intentionné que d'une faille de sécurité..

            Enfin, si il y a une faille de sécurité, mais je crois pas qu'elle se situe dans le noyau linux dans ce cas-là :-)
          • [^] # Re: Exploitabilité *réelle*

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

            >y'a un technicien, ou un développeur, qui a un compte,

            Ou une faille dans le code d'un site. Tu uploade l'exploit, tu ouvre un shell avec la fonction exec de n'importe quel langage de script, tu passe root et voilà.

            Si le type est pas trop con, il peut se balader pendant des jours, piquer des infos, installer des backdoors des phishings, balancer du spam et même s'il a de la chance récupérer des screens, des clés sans passphrases (genre pour les backup) et compromettre tout ton parc
      • [^] # Re: Exploitabilité *réelle*

        Posté par  (Mastodon) . Évalué à 1.

        Erf, j'ai fait à peu près la même avec un compte de test www/www.
        Le « serveur » à l'époque (~2004) était un vieux 486.
        Le type est passé root et a essayé d'installer un ircbot, et tout.
        La charge était tellement énorme pour une si petite machine, qu'il l'a juste mise à genoux, j'ai repéré tout de suite qu'il y avait un problème (plus d'accès internet... plus d'accès au routeur, ah !), débranché le câble et réglé le problème en direct.

        Depuis, plus rien, plus personne ne passe...

        Yth.
      • [^] # Re: Exploitabilité *réelle*

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

        +1 pour le servuer sous BSD. Mais ça ne te protègera pas d'erruers humaines, et les BSD, comme tout logiciels ne sont pas exempts de failles. Mais tout ça tu le savais déjà.
        Faits juste attention, une fois qu'on à goûté à BSD on ne peut plus s'en passer ;)
        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 1.

          Faits juste attention, une fois qu'on à goûté à BSD on ne peut plus s'en passer ;)
          C'est principalement ce genre de remarques qui me fait envie de tester, justement..

          D'abord on utilise un truc, on trouve que c'est bien, puis on découvre quelque chose qui est carrément mieux mais différent à prendre en main, au début on galère puis quand on s'y est fait, on se demande "Mais comment j'ai pu utiliser un truc aussi moisi avant?" et on n'a plus aucune envie de revenir en arrière.
          C'est l'impression que donne une migration Windows => GNU/Linux, et j'attends la même chose d'un passage de GNU/Linux à BSD ;+)

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Exploitabilité *réelle*

        Posté par  . Évalué à 2.

        Sinon dans man sshd_config, on découvre un paramètre très utile pour ce genre d'erreur : AllowUsers ... pis tant que tu y es, tu peux aussi rajouter PermitRootLogin no.

        C'est aussi valable sous *BSD ;)

        Sans être un maniaque de la sécurité, il y a quelques règles très simple à mettre en place sur tout linux fraîchement installé :
        - limité le nombre de services réseaux (ou pas) au maximum.
        - sécurisé un minimum ces points d'entrées.

        Après, utiliser/configurer iptables aux petits oignons sur un desktop, c'est plus un luxe que vraiment utile amha.
    • [^] # Re: Exploitabilité *réelle*

      Posté par  . Évalué à 5.

      Un exemple qui me vient en tête : à l'université. J'imagine que si les élèves peuvent avoir un accès root rien qu'en lançant un shell-script, ça craint...

      Je sais que moi, si j'avais eu connaissance d'une telle faille il y a quelques années, il y aurait eu petit diable sur mon épaule droite pour me dire : Alleeeer, tente l'exploit, juste pour voir si les admins font bien leur boulot c'est tout. ;-)

      Surtout que dans mon cas (mais j'imagine que c'est courant), on pouvait se connecter à n'importe quel compte à partir de n'importe où et accéder à toutes les données, vu que les utilisateurs et les données étaient partagées (NFS, etc.). On pouvait déjà dénicher des informations assez intéressantes grâce aux droits mal réglés de certains étourdis, mais si en plus on peut les modifier...

      Alek.
      • [^] # Re: Exploitabilité *réelle*

        Posté par  . Évalué à 6.

        Me fait penser à la réaction idiote d'un pote geek qui avait un serveur dédié..
        il était root dessus (normal, c'est lui qui payait le dédié) et il y avait plusieurs comptes utilisateurs.

        En apprenant l'existence d'une faille du noyau Linux qui permettait de passer root depuis un compte utilisateur, je lui en cause..

        Il me fait "Ah mais attends c'est une faille locale??"
        Moi: "Ben oui. Les utilisateurs locaux peuvent devenir root."
        Lui: "Ah ben ça risque rien alors, y'a personne en local sur le serveur, on y accède à distance via SSH..."

        Bon, il s'est vite rendu compte de son erreur.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Exploitabilité *réelle*

        Posté par  . Évalué à 2.

        Dans mon université l'expoit fonctionne, et oui je peux avoir un accès root à toutes les données de la fac.

        Je n'ai pas envie de faire mon salaud mais, j'avoue que c'est assez tentant.

        En fait je me pose plutôt la question : est-ce que j'envoie un mail aux admins. du parc pour leurs faire comprendre qu'ils sont incompétent ?

        Affaire à suivre ^^
        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 2.

          J'ai une autre idée : comme tu as fait tes preuves, tu proposes d'intégrer l'équipe d'admin pour sécuriser tout ça. Rémunéré, bien sûr ;-)

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Exploitabilité *réelle*

            Posté par  . Évalué à 3.

            Ça rappelle une anecdote célèbre (?) concernant une non moins célèbre école d'informatique française, et un de ses administrateurs système.
        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 3.

          Tu leur envoies un mail depuis le compte root@machine, ça fait toujours son effet sur un admin.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Exploitabilité *réelle*

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

          Attention, si tu enfreins la charte informatique...

          Système - Réseau - Sécurité Open Source

        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 3.

          Il faut bien connaître les admins... Parce qu'aller dire que tu as commis un acte illégal (s'introduire dans un système, même sans rien faire d'autre, est illégal il me semble), c'est un peu te jeter dans la gueule du loup si jamais ils ne sont pas très ouverts... Et même s'ils le sont et qu'ils comprennent bien ta démarche, peuvent-ils garder une telle intrusion secrète sans que ce soit une faute de leur part ? Ne doivent-ils pas vérifier et faire vérifier par précaution que tu n'as vraiment rien fais ?

          Mhh déjà je serais toi j'effacerais bien toute trace car si des admins d'université trainent dans le coin, nul doute qu'ils vont faire un petit find . -name enlightenment.tgz pour te trouver. ;-)

          Alek.
        • [^] # Re: Exploitabilité *réelle*

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

          Tu leur envoie un mail, sans leur dire qu'ils sont incompétants (ça a beaucoup de fierté un admin, et beaucoup de pouvoir de nuisance aussi), leur parlant de la faille, avec des liens vers les "advisories" et pourquoi pas vers ce journal, ainsi il verrons que l'exploit fonctionne très bien. et tu leur demande juste si les machines de l'université ont bien été protégées contre ce problème.
          Ils te diront certainement que oui ;), et feront le tour des serveurs pour appliquer le workaround en attendant les mises à jours officielles du noyau et des distribs.
        • [^] # Re: Exploitabilité *réelle*

          Posté par  . Évalué à 3.

          j'enverrais un mail sans rien chercher à minimiser :
          si tu as vraiment testé la faille par curiosité et que tu n'as rien à te reprocher, il vaut mieux les prévenir carrément que la faille est exploitable en l'état, avec un peu de liens d'info et le patch, et qu'ils feraient mieux de faire vite

          un bon admin te remerciera, un mauvais t'engueulera parce que c'est vendredi après midi
          • [^] # Re: Exploitabilité *réelle*

            Posté par  . Évalué à 9.

            un mauvais t'engueulera parce que c'est vendredi après midi

            Mais non, car c’est justement le vendredi après-midi, juste avant de partir en week-end de trois jours, ou carrément en vacances, que le mauvais admin décide de modifier toute la configuration des serveurs, directement en production, sans test, pour tout foutre en l’air et pouvoir demander une augmentation à son retour vu que, quand il est absent, il n’y a plus rien qui marche…
          • [^] # Re: Exploitabilité *réelle*

            Posté par  . Évalué à 1.

            Personnellement, je leur ferai remarquer que /proc/sys/vm/mmap_min_addr à une valeur nulle et que donc le système est potentiellement vulnérable. Cela avec les liens qui vont bien.
    • [^] # Re: Exploitabilité *réelle*

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

      Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès.

      Sais-tu que les navigateurs web sont devenus le principal point d'entrée des malwares ? Les failles (HTML, Javascript, Flash, etc.) sont très courantes. Si un pirate arrive à exécuter du code dans ton navigateur web, c'est comme si c'était un utilisateur local. Avec ça, il peut déjà voir tes photos de vacances, lire tes mails, sniffer tous tes mots de passe, récupérer tes clés SSH/GPG, etc. C'est déjà pas mal.

      Maintenant, en utilisant un exploit pour passer root, il peut modifier le système, très utile pour la furtivité (supprimer quelques lignes compromettantes dans des fichiers de log, compiler et charger un module noyau à la volée, remplacer tes programmes par des versions piratées, etc.). Ça permet également de mettre en place un serveur web, FTP et/ou ssh : un utilisateur ne peut pas écouter sur les ports TCP inférieurs à 1024 (bien qu'on puisse très bien utiliser des ports non standards, mais c'est moins furtif, après ça dépend des usages).

      Bien sûr, le navigateur n'est pas le seul vecteur d'entrée. N'importe quel support amovible (clé USB, disque dur externe, CD/DVD) et tout ce qui vient d'Internet (web, mail, photos, paquets, etc.) peut servir pour infecter ta machine.

      Aujourd'hui, le plus grand fléau sont les botnets qui servent à envoyer du spam : des troyans s'installent sur des postes Windows. Des postes de travail, pas des serveurs, car justement le but est d'avoir le botnet le plus gros possible, donc infecter le maximum d'ordinateurs.

      Je n'essaye pas de te rendre parano, juste de t'expliquer les risques ;-) C'était pour dire que même si tu n'as aucun port en écoute, tu n'es pas protégé pour autant.
  • # s/RedHat/Red Hat Enterprise Linux/g

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

    http://www.redhat.com/f/pdf/corp/trademark_usage.pdf

    Vous pouvez aussi gagner du karma en dénonçant le fait que ce PDF a été généré avec des outils propriétaires.

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

Suivre le flux des commentaires

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