Journal Mets à jour ton bash. Maintenant.

Post√©¬†par¬† . Licence CC¬†By‚ÄĎSA.
55
24
sept.
2014

Bonjour, Nal

Un journal bookmark pour signaler : faut mettre à jour bash
Voilà, c'est tout. Vous pouvez reprendre une activité normale.

Pour les autres, qui ne vont pas reprendre une activité normale de suite, on pourra résumer cela en "c'est sérieux, urgent, et mérite peut être une campagne de patch au pied levé". Cette découverte, qui date d'une vingtaine de jours aujourd'hui, vient d'avoir ses correctifs validés, à priori (…).
Sans cela, il est possible de faire, par exemple :

  • Faire joujou avec le mod_cgi de Apache (mod_php n'est pas affect√© cependant)
  • Utiliser un serveur dhcp craft√© pour renvoyer des jouets √† un dhclient ‚Ķ
  • Faire joujou avec les binaires √† bit suid‚Ķ
  • etc, etc‚Ķ genre s'amuser avec forcecommand sur sshd

Un exemple pour savoir si vous n'êtes pas concernés (vous l'êtes probablement …) :

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt

  • # Alternatives

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†1.

    Ça peut également être l'occasion de passer à un autre shell comme zsh (mais ça n'empêche pas de faire la mise à jour de bash).

    • [^] # Re: Alternatives

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†7.

      Sauf à faire pointer sh vers zsh, je pense que ça va pas changer grand chose. J'ai pas testé ce que ça donne avec dash par contre.

      • [^] # Re: Alternatives

        Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†5.

        En effet, ce serait tout à fait inutile. Le shell interactif de l'utilisateur n'est pas le problème (puisqu'on exécute le script avec ses privilèges), le problème est le /bin/sh du système, qui est appelé à des tas d'occasions.

      • [^] # Re: Alternatives

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†2. Derni√®re modification le 25/09/14 √† 13:06.

        Dash me semble épargné :
        $ env x='() { :;}; echo vulnerable' dash -c "echo this is a test"
        this is a test

        Je pense quand m√™me que quelqu‚Äôun de pas trop b√™te voulant exploiter cette faille dans un script ne d√©clarera pas #!/bin/sh mais plut√īt #!/bin/bash.

        • [^] # Re: Alternatives

          Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†10.

          Euh, si l'attaquant peut écrire le script à volonté oui, mais, en pratique, dans une attaque à distance, l'attaquant n'a pas le choix, il doit exploiter les scripts existants sur le serveur :-)

        • [^] # Re: Alternatives

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

          Sur ce coup gloire à dash !
          Avec tout le parc ubuntu l'utilisant à la place de bash comme /bin/sh (j'imagine que c'est pareil pour debian), ça exclu quand même un bon nombre de serveur.

          √Čvidemment jusqu'√† ce qu'une faille analogue soit trouv√©e dans dash‚Ķ √† ce moment il nous restera eshell¬†!

          • [^] # Re: Alternatives

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†1.

            Heu. Sous Ubuntu, le terminal utilise bien Dash, right? Moi j'étais vulnérable.

          • [^] # Re: Alternatives

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†1.

            √Čvidemment jusqu'√† ce qu'une faille analogue soit trouv√©e dans dash‚Ķ √† ce moment il nous restera eshell¬†!

            Ou Powershell.

          • [^] # Re: Alternatives

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 26/09/14 √† 12:21.

            Busybox sh est aussi épargné (et heureusement, vu le nombre de systèmes embarqués l'utilisant qui ne sont/seront pas mis à jour !)

        • [^] # Re: Alternatives

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

          bash aussi est épargé, pour peu qu'on le lance en mode posix (-p):

          $ env x='() { :;}; echo vulnerable' bash -p -c "echo this is a test"
          this is a test
          Cette vulnérabilité exploite un bash-ism (possibilité d'exporter une fonction, pas juste une variable d'environnement).

  • # Quitte √† citer

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

    Quitte à pointer vers une ressource du grand satan pousseur de systemd avec un chapeau rouge, autant pointer vers le blog qui explique les détails :

    https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

    Et vers le thread sur oss-sec :

    http://www.openwall.com/lists/oss-security/2014/09/24/10

    Notamment

    http://www.openwall.com/lists/oss-security/2014/09/24/12

    Perso, j'ai pas de cgi, j'ai mon dhclient qui tourne avec un domaine selinux confiné. Et j'ai pas de serveur git avec forcecommand ( j'ai des rsync par contre, mais ça implique d'avoir la clé à priori ). Donc je vais pas stopper tout pour la mise à jour, je vais finir ma pizza ( au contraire de Linuxfr, qui lui est important )

    maintenant, si vous avez gitolite, et que vous êtes dans un hotel chelou rempli de linuxien, ça me parait plus critique que pour moi :)

  • # pas si valid√© que √ßa

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†7.

    https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23

    Il semblerais que ça ne soit pas fini. Bon, ben j'ai bien fait d'automatiser avec ansible mes upgrades d serveur.

    • [^] # Re: pas si valid√© que √ßa

      Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†10.

      En effet, et un nouveau CVE a été attribué pour suivre cette vunérabilité dans la vulnérabilité, CVE-2014-7169. Attendez vous à un patch du patch http://seclists.org/oss-sec/2014/q3/685

    • [^] # Re: pas si valid√© que √ßa

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

      Bah tu pourrais utiliser salt ;-)

      Liste des machines concernées

      % salt -v \* cmd.run "env x='() { :;}; :; echo bad' bash -c : 2>&1|grep bad"

      Mettre à jour :

      % salt -v pkg.install bash refresh=True
      • Rev√©rifier ensuite la liste des machines concern√©es

      On peut préciser qu'on ne veut tester que les linux : "salt -v -G 'kernel:Linux'…" mais je pense que c'est une mauvaise idée.

      • [^] # Re: pas si valid√© que √ßa

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        Gloups j'ai oublié le ciblage dans la seconde commande, mais c'est un exercice laissé au lecteur, hop :-)

  • # CVE-2014-6271

    Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†10.

    Quand on signale une faille de sécurité, cela vaut vraiment la peine d'indiquer le CVE. Cela permet de retrouver plus facilement. Donc, CVE-2014-6271

  • # Il est urgent de mettre √† jour

    Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†6.

    Tous les script-kiddies de la planète sont à l'attaque depuis hier soir, notamment contre les sites Web : https://gist.github.com/anonymous/929d622f3b36b00c0be1

    • [^] # Re: Il est urgent de mettre √† jour

      Post√©¬†par¬† (Mastodon) . √Čvalu√©¬†√†¬†5.

      Je comprends pas le rapport entre bash (outil nécessitant l'accès à un compte) et une attaque sur un serveur web. Qqu'un peut expliquer ?

      Merci d'avance :)

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Il est urgent de mettre √† jour

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†8.

        Il faut lire l'article déjà cité ;)

        Par exemple un serveur Apache utilisant PHP avec mod_cgi sera affecté si les fonctions permettant d'utiliser un shell (exec, shell_exec, …) sont actives.

      • [^] # Re: Il est urgent de mettre √† jour

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

        outil nécessitant l'accès à un compte

        Ben non justement, bash est très souvent exécuté par d'autres programmes, notamment des serveurs, selon leurs fonctionnalités. Par exemple, les scripts CGI. Dans ce cas le serveur fait appel au shell, positionne des variables d'environnement, or il y a un bug qui permet d'exécuter du code lors de la définition de la variable d'environnement.

        • [^] # Re: Il est urgent de mettre √† jour

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

          Deux exemples concrets :

          • dhclient ex√©cute des scripts bash en root, et deux des variables d'environnement qu'il positionne contiennent directement le texte envoy√© par le serveur DHCP. Si quelqu'un branche un serveur DHCP modifi√© et hostile sur le r√©seau, il peut en cons√©quence ex√©cuter des scripts shell en tant que root sur chaque machine cliente DHCP.

          • SSH positionne la variable d'environnement SSH_ORIGINAL_COMMAND avec la commande re√ßue par le client. C'est le cas m√™me quand SSH est configur√© (avec ForceCommand) pour n'ex√©cuter qu'une seule commande sur le serveur (cas de Git ou Subversion, notamment). De cette mani√®re, un client hostile peut contourner la restriction √† une seule commande, et ex√©cuter ce qu'il veut sur le serveur, notamment t√©l√©charger un exploit. Tous les d√©p√īts Git et Subversion (ou autre) accessibles par SSH sont concern√©s.

          Au passage, sachez qu'OS X est également vulnérable.

          • [^] # Re: Il est urgent de mettre √† jour

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10.

            Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.

            sesearch -T --allow -s dhcpc_t | grep type_transition | grep process

            va lister les domaines vers lesquelles dhcp_t peut faire une transition.

            sesearch --allow -s dhcpc_t | grep execute

            va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).

            Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.

            A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.

            Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.

            Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.

            Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable
            https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.

            • [^] # Re: Il est urgent de mettre √† jour

              Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†9.

              P'tain c'est carrément un sacré plaidoyer pour SELinux, très loin devant mes gesticulations pour le défendre dans le sondage en cours face aux "lolol SELinux ça fait chier je le désactive direct" ! J'suis jaloux.

          • [^] # Re: Il est urgent de mettre √† jour

            Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†4.

            sachez qu'OS X est également vulnérable.

            z/OS aussi http://mainframed767.tumblr.com/post/98446455927

            • [^] # Re: Il est urgent de mettre √† jour

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

              Pour ceux qui seraient surpris comme moi:

              Keep in mind, z/OS doesn’t come with Bash, they offer an unsupported binary/source for you to install, and you have to seek it out yourself if you want to use it. /bin/sh is the default and isn’t vulnerable (that I’m aware).

              ¬ę 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: Il est urgent de mettre √† jour

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

        De ce que j'ai pu lire, le module CGI d'Apache recopie certains entêtes HTTP dans les variables d'environnement.
        Pour ma part, je n'ai pas réussi à reproduire avec du fCGI.

        alf.life

        • [^] # Re: Il est urgent de mettre √† jour

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5. Derni√®re modification le 25/09/14 √† 17:57.

          Pas que Apache : c'est la définition même de CGI. Rien de tel pour FastCGI, qui est un protocole pour, non pas lancer des binaires, mais pour causer à un serveur d'exécution, en lui passant, non pas des variables d'environnement parce que ce n'est pas le serveur Web qui le lance, mais des variables tout court. Il est en revanche possible qu'un serveur FastCGI transforme ces variables en variables d'environnement pour les trucs qu'il lancera, mais je doute que ce soit utilisé en pratique, parce que ça reviendrait à faire du CGI.

      • [^] # Re: Il est urgent de mettre √† jour

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†-3.

        Hello,

        Certaines requêtes HTTP conduisent à l’exécution de script sur le serveur en général ce sont des scripts exécutés via l'interpréteur bash.

        Or premièrement, il est fortement conseillé de chrooter sont serveurs web, surtout lors de l'utilisation de cgi-scripts (c'est le nom des ce type de requête web), ensuite, il est aussi utile de protéger les commandes transmises au shell, tout comme il faut le faire avec les requêtes sql afin d'éviter les SQL injection.

        Enfin, même si cette faille est assez grave, il est possible, en utilisant à chaque étape un minimum de sécurité (chroot, utilisateur sans droit, installation minimal des serveurs…), de s'en protéger, mais là encore, il faut mieux éviter les environnement "tout prêt", et préférer perdre un peu de temps à bien comprendre ce que l'on attend de son serveur, et n'installer que les éléments nécessaires pour l'obtenir … ;-)

        • [^] # Re: Il est urgent de mettre √† jour

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†0.

          chroot != sécurité !

          "Quand certains r√Ęlent contre systemd, d'autres s'attaquent aux vrais probl√®mes." (merci Sinma !)

          • [^] # Re: Il est urgent de mettre √† jour

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†2.

            Tu peux d√©velopper un peu‚ÄĮ?
            Je sais que "chroot" n‚Äôest pas synonyme de "s√©curit√©", et qu‚Äôon peut m√™me en sortir assez facilement si on conna√ģt la m√©thode, mais n‚Äôest-ce pas une s√©curit√© suppl√©mentaire si combin√© √† d‚Äôautres bonnes pratiques‚ÄĮ?

            (je suis tout juste en train de mettre en place mon premier serveur http‚ÄĮ+‚ÄĮftp, consid√®re que je ne connais encore pas grand chose sur ce sujet)

          • [^] # Re: Il est urgent de mettre √† jour

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

            Oui, il y a schroot pour ça :-)

            Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

          • [^] # Re: Il est urgent de mettre √† jour

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†2. Derni√®re modification le 26/09/14 √† 07:06.

            Post√© par xcomcmdr le 25/09/14 √† 13:22. √Čvalu√© √† 1 (+1/-2) .
            chroot != sécurité !

            Explique !

            • [^] # Re: Il est urgent de mettre √† jour

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

              A cause de tout ce qu'on trouve sur google à ce sujet.
              En gros :
              - si un process passe root t'es mort
              - il suffit d'avoir un hardlink un peu foireux pour en sortir
              - ca ne fournit qu'une isolation bancale du système de fichier, et aucunement du réseau, de la mémoire, des processus et probablement aussi pour les IPC.

              C'est une couche de sécurité supplémentaire (épaisseur genre nuisette), mais qui est totalement insuffisante toute seule en 2014.

              • [^] # Re: Il est urgent de mettre √† jour

                Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

                C'est une couche de sécurité supplémentaire (épaisseur genre nuisette), mais qui est totalement insuffisante toute seule en 2014.

                D'après Alan Cox, c'était aussi insuffisant tout seul en 2007, la raison étant que chroot n'a pas été conçu pour servir de couche de sécurité. On ne peut pas reprocher à un outil de ne pas répondre à un besoin auquel il ne cherche pas à répondre.

  • # Les attaques de serveur ont d√©j√† commenc√©

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†10. Derni√®re modification le 25/09/14 √† 11:33.

    Vu dans les logs de mon serveur perso :

    209.126.xxx.xx - - [25/Sep/2014:00:09:36 +0200] "GET / HTTP/1.0" 200 71 "() { :; }; ping -c 11 216.75.xx.xx" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
    209.126.xxx.xx - - [25/Sep/2014:07:44:15 +0200] "GET / HTTP/1.0" 200 71 "() { :; }; ping -c 11 209.126.xxx.xx" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
    89.207.xxx.xxx - - [25/Sep/2014:10:55:48 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 200 71 "-" "() { :;}; /bin/ping -c 1 198.101.xxx.xxx"

    Deux scans d'un white hat qui laisse poliment une URL dans les logs pour expliquer sa démarche. Et puis un scan beaucoup plus gris, voire noir… Heureusement qu'ils se sont contentés d'un ping.

  • # Debian Squeeze (version 6)

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†10.

    Pour ceux qui sont (encore) en Debian Squeeze (version 6), il faut penser √† ajouter le d√©p√īt "squeeze-lts".

    Par ex:

    deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
    deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

    La version de bash patchée est la 4.1-3+deb6u1
    Pour plus de détails, voir: CVE-2014-6271 @ Debian tracker

    • [^] # Re: Debian Squeeze (version 6)

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

      J'étais surpris de ne pas voir de mise à jour mais j'ai fini par penser à la LTS.

      Du coup j'ai du mal √† voir l'int√©r√™t de rajouter un d√©p√īt alors qu'il y a d√©j√† squeeze/security con√ßu pr√©cis√©ment pour ce cas‚Ķ

      Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

      • [^] # Re: Debian Squeeze (version 6)

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        Du coup j'ai du mal √† voir l'int√©r√™t de rajouter un d√©p√īt alors qu'il y a d√©j√† squeeze/security con√ßu pr√©cis√©ment pour ce cas‚Ķ

        Les mises √† jour de s√©curit√© de Squeeze ne sont officiellement plus prises en charge par le projet Debian depuis le 31 mai 2014. Il n'y aura donc rien dans le d√©p√īt squeeze/security.

        • [^] # Re: Debian Squeeze (version 6)

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†7.

          Très bien.

          Mais encore une fois, pourquoi ajouter un d√©p√īt, et ne pas reprendre l'ancien qui est d√©j√† configur√© partout¬†?

          Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

          • [^] # Re: Debian Squeeze (version 6)

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†7.

            Parce que Linux est user-friendly.
            GNU/Linux, pardon.

          • [^] # Re: Debian Squeeze (version 6)

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†7. Derni√®re modification le 25/09/14 √† 18:13.

            Raison administrative : ce ne sont pas les mêmes équipes, et pas la même couverture en terme de paquets pris en charge.

            Pour la m√™me raison, en somme que le d√©p√īt security est distinct des d√©p√īts normaux de la distribution.

    • [^] # Re: Debian Jessie

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

      Attention pour celles et ceux qui sont (déjà) en Jessie, la correction ne sera effective que dans quelques jours ("descente" de unstable)

      Has the Bash vulnerability been fixed on Jessie yet?

      Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

      • [^] # Re: Debian Jessie

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

        Bah et testing-security, ça sert à quoi ?

        Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

        • [^] # Re: Debian Jessie

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†1.

          C‚Äôest un d√©p√īt qui ne prend son int√©r√™t que dans un monde utopique avec suffisamment de d√©veloppeurs/mainteneurs/empaqueteurs.

          • [^] # Re: Debian Jessie

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

            C'est s√Ľr que si on s'amuse √† cr√©er des d√©p√īts surnum√©raires (lts en plus de security), √©videmment qu'il n'y a plus assez de mains‚Ķ

            Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

            • [^] # Re: Debian Jessie

              Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

              Le d√©p√īt lts a √©t√© mont√© par une √©quipe de volontaires voulant prolonger la dur√©e de vie de Squeeze, ce n‚Äôest pas l‚Äô√©quipe security habituelle qui s‚Äôen charge.
              Normal donc que ces mises-√†-jours ne soient pas fournies dans le m√™me d√©p√īt, vu qu‚Äôelles ne viennent pas avec les m√™mes garanties.

              • [^] # Re: Debian Jessie

                Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

                Le d√©p√īt lts a √©t√© mont√© par une √©quipe de volontaires voulant prolonger la dur√©e de vie de Squeeze, ce n‚Äôest pas l‚Äô√©quipe security habituelle qui s‚Äôen charge.

                Attends, tu veux dire que la version de Debian sortie en 2011 (https://wiki.debian.org/fr/DebianSqueeze 06-02-2011 : Publication initiale) est abandonnée avant 2014 ???

                Si on prend une Debian, soit-disant le parangon des OS serveurs pérennes, on peut s'attendre au mieux à 2 ans de support, et après c'est à la bonne volonté du voisin ?

                Euh sans tomber dans l'extrême inverse de l'acharnement thérapeutique sur XP, 2 ans de support c'est une blague ? Autant prendre une Fedora qui a (2 versions + 1 mois) de support, au final c'est pas loin de faire autant. Et ne parlons pas d'une vraie distrib pro avec une politique sérieuse…

                • [^] # Re: Debian Jessie

                  Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

                  Il me semble que Debian n'a jamais été faite pour les gens qui veulent un truc sur du long terme. Lorsqu'une nouvelle version sort, ça veut dire qu'il faut migrer dans l'année pour être large.

                  Et visiblement ce comportement convient à beaucoup de gens, et à d'autre moins (cf debian-lts). Et visiblement, peu de monde sont prêt à investir (des sous) dans debian-lts, malheureusement.

                  • [^] # Re: Debian Jessie

                    Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

                    Il y a aussi le problème de garder une version précise d'un logiciel comme php 5.3 par exemple ou des logiciels maison.

                    Dans ce cas, le plus simple est de ne pas mettre à jour.

                    • [^] # Re: Debian Jessie

                      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

                      Dans ce cas, le plus simple est de ne pas mettre à jour.

                      Et donc de rester vuln√©rable √† des failles comme celle dont on discute ici‚ÄĮ?

            • [^] # Re: Debian Jessie

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

              Je ne crois pas que le fait de cr√©er un d√©p√īt change grand chose quant √† la r√©activit√© des packageurs. lts existe probablement pour s√©parer une nouvelle phase de vie de la distribution et parce que ce ne sont pas les m√™me personnes qui s'occupent de debian stable et de la LTS. Quand on utilise testing faut pas d√©conner √ßa fait un bail qu'on dit √† tut t√™te que les MAJ de s√©curit√© mettent plus de temps √† arriver, il ne faut pas √™tre surpris quand on en a l'exemple. Pour rappel elle s'appelle Debian Testing.

              Pour donner des exemples si tu va sur le wiki officiel Debian sur la page de testing tu pourra lire :

              Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.

              Il est aussi question du d√©p√īt testing security :

              Q. : Comment est gérée la sécurité pour testing  ?

              R. : La s√©curit√© pour testing b√©n√©ficie des efforts sur la s√©curit√© r√©alis√©s par tout le projet pour unstable. Cependant, un d√©lai minimal de deux jours existe pour la migration, et les correctifs de s√©curit√© peuvent parfois √™tre retenus par les transitions. L‚Äô√©quipe charg√©e de la s√©curit√© aide √† faire avancer ces transitions qui retiennent les envois de s√©curit√© importants, mais ce n‚Äôest pas toujours possible et des contretemps peuvent survenir. En particulier, les mois qui suivent une nouvelle publication de stable, quand de nombreuses nouvelles versions sont envoy√©es dans unstable, les correctifs de s√©curit√© pourraient √™tre mis en attente. Si vous souhaitez un serveur s√Ľr (et stable), vous devriez garder la distribution stable.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Debian Jessie

                Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

                Quand on utilise testing faut pas déconner ça fait un bail qu'on dit à tut tête que les MAJ de sécurité mettent plus de temps à arriver, il ne faut pas être surpris quand on en a l'exemple. Pour rappel elle s'appelle Debian Testing

                Oui, mais alors il faut reconna√ģtre que "testing-security" est assez trompeur comme nom, surtout quand c'est explicitement d√©crit dans la doc :-)

                Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

                • [^] # Re: Debian Jessie

                  Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

                  Je ne vois pas o√Ļ est le probl√®me. Ce d√©p√īt int√®gre les mises √† jour de s√©curit√© elles sont pas aussi rapide que pour les deux autres versions, c'est tout.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Debian Jessie

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

          A améliorer la sécurité, pas à la rendre parfaite.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Debian Jessie

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

            Ça améliore vachement la sécurité alors : la correction est disponible pour stable et unstable mais pas testing.

            Qu'on se comprenne bien, Debian reste la distro que je préfère techniquement, mais parfois les choix administratifs me paraissent tellement éloignés des vrais préoccupations des utilisateurs et même de la philosophie du projet…

            Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

            • [^] # Re: Debian Jessie

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

              Ça améliore vachement la sécurité alors : la correction est disponible pour stable et unstable mais pas testing.

              La correction est arriv√©e en moins de 2 jours l√† o√Ļ avant elle aurait mis 10 jours. L'une des m√©triques importantes pour mesurer la s√©curit√© d'un syst√®me informatique c'est le temps qu'une correction met a arriver. Ils ont r√©duit ce chiffre de 80%, si tu ne vois pas le gain je ne peux pas y faire grand chose.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Debian Jessie

                Post√©¬†par¬† . √Čvalu√©¬†√†¬†-1.

                2 jours pour une faille de sécurité majeure même si 80% plus rapide ça reste non admissible.

                • [^] # Re: Debian Jessie

                  Post√©¬†par¬† . √Čvalu√©¬†√†¬†8.

                  N'importe quoi. Du moins tant que tu ne m'a pas donné de critères complets.
                  La faille est resté quelque soit le système d'exploitation que tu utilise pendant une vingtaine d'année, si j'ai bien compris et le bug est connu depuis au moins le 14 septembre, la mise à jour upstream a mis quelques jours. Je crois pas qu'il y ai eu de mise à jour des distrib' avant le 24. Donc avant toute chose c'est bien de mettre en balance les délais. Les 10 jours entre le fait que la faille soit connue et l'application des correctifs tout le monde se l'est pris.

                  Ensuite et encore une fois l'objectif de testing-security n'est pas que tu trouve ça acceptable, juste d'améliorer un peu la sécurité d'une version de test de Debian. Si tu as des critères importants de sécurité lis la doc de ce que tu installe et n'installe pas testing, personne ne t'en voudra.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Debian Jessie

                Post√©¬†par¬† . √Čvalu√©¬†√†¬†0.

                La correction est surtout arrivée partout ailleurs, chez Debian (stable et unstable) ou chez Red Hat et autres, mais pas chez testing.

                Tout l'int√©r√™t d'avoir un d√©p√īt d√©di√© √† la s√©curit√© est que √ßa soit le plus rapide possible pour ce genre de cas. S'il faut attendre plus longtemps que les autres alors que le correctif existe, √ßa ruine un peu l'id√©e de base, mais ce n'est que mon avis.

                Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

                • [^] # Re: Debian Jessie

                  Post√©¬†par¬† . √Čvalu√©¬†√†¬†7.

                  Ben j'sais pas change de version, lis la doc de ce que tu utilise avant d'imaginer,…

                  La correction est surtout arrivée partout ailleurs, chez Debian (stable et unstable) ou chez Red Hat et autres, mais pas chez testing.

                  La première (la CVE-2014-6271) correction est arrivé dans testing (hier soir ou dans la nuit si je ne m'abuse), toute fois la seconde (celle qui est arrivé dans les autres versions de Debian ce matin) n'y est toujours pas.

                  C'est rigolo de faire celui qui est choqué par le temps que ça prend sans regarder le temps que ça prend.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Debian Jessie

                    Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

                    Ben j'sais pas change de version, lis la doc de ce que tu utilise avant d'imaginer,…

                    T'inquiète, je suis sous stable pour tout ça suffit amplement (bien qu'il me reste encore une squeeze que j'ai la flemme de passer en wheezy).

                    La première (la CVE-2014-6271) correction est arrivé dans testing (hier soir ou dans la nuit si je ne m'abuse), toute fois la seconde (celle qui est arrivé dans les autres versions de Debian ce matin) n'y est toujours pas.

                    C'est rigolo de faire celui qui est choqué par le temps que ça prend sans regarder le temps que ça prend.

                    Oui m'enfin lorsque nous avons commenc√© cette conversation, la maj √©tait dispo sur stable et unstable mais pas testing. C'est s√Ľr, les trolls aident √† faire passer le temps donc depuis oui c'est dispo partout (ou presque, comme tu le soulignes).

                    Et je ne suis pas choqué, je ne fais que pointer ce que je considère comme une petite incohérence. Si on ne peut plus critiquer, autant rester sous Windows :-)

                    Article Quarante-Deux¬†: Toute personne d√©passant un kilom√®tre de haut doit quitter le Tribunal.¬†-- Le Roi de CŇďur

      • [^] # Re: Debian Jessie

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

        Affaire r√©gl√©e¬†: le correctif est arriv√©e en Jessie‚ÄĮ!

      • [^] # Re: Debian Jessie

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†1. Derni√®re modification le 25/09/14 √† 20:06.

        En fait c'est déjà arrivé.

        jjl@guiautec:~$ zcat /usr/share/doc/bash/changelog.Debian.gz |head
        bash (4.3-9.1) unstable; urgency=high
        * Non-maintainer upload by the security team
        * Apply upstream patch bash43-025, fixing CVE-2014-6271.

        https://packages.debian.org/jessie/bash

        Edit: grillé, j'avais pas rechargé la page :)

  • # Pas compris le probleme....

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†-3.

    C:\Users\nvidiatnt>bash
    'bash' is not recognized as an internal or external command,
    operable program or batch file.

    C'est quoi exactement le danger ? ;)

    • [^] # Re: Pas compris le probleme....

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

      Blague √† part, est ce que Service For Unix / Subsystem for UNIX-based Applications a √©t√© mis √† jour‚ÄĮ?

      Je ne trouve pas de version plus r√©cente que celle-ci qui date du 31 octobre 2012‚ÄĮ!

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Pas compris le probleme....

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        Aucune idee je bosses plus chez eux. Mais t'es sur que SFU inclue bash ? Il me semblait que c'etait csh et ksh

        • [^] # Re: Pas compris le probleme....

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4. Derni√®re modification le 25/09/14 √† 21:38.

          Ah oui au temps pour moi !

          $ 7z l 'Utilities and SDK for Subsystem for UNIX-based Applications_x86.exe' | grep 'sh.bat'
          2009-03-31 05:55:18 ....A          262          193  BaseUtils/common/csh.bat
          2009-03-31 05:55:18 ....A          261          193  BaseUtils/common/ksh.bat
          

          Je lis ici que bash est un outil distribué par des tiers et qu’exactement ce sont les implémentations pdksh et tcsh qui sont distribuées. Tu marques un point. ;-)

          Cela dit, j’espère que depuis 2009 il n’y a pas eu de faille majeure dans ces deux projets. :-)

          Aucune idee je bosses plus chez eux.

          ¬ę‚ÄĮchez eux‚ÄĮ¬Ľ, √ßa signifie que tu as chang√© de service ou que tu n‚Äôes plus chez Microsoft‚ÄĮ?

          Et sinon, complètement HS, c’est étonnant comme identifiant de session utilisateur ça, nvidiatnt, surtout avec le nom d’une techno plus ancienne (~1998) que le nommage de l’arborescence C:\Users (~2006). %)

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Pas compris le probleme....

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

            Cela dit, j’espère que depuis 2009 il n’y a pas eu de faille majeure dans ces deux projets. :-)

            Si il y en a eu et qu'elles affectent SFU, elles seront patchees. SFU n'est peut-etre plus developpe, mais il est toujours en mode maintenance.

            ¬ę‚ÄĮchez eux‚ÄĮ¬Ľ, √ßa signifie que tu as chang√© de service ou que tu n‚Äôes plus chez Microsoft‚ÄĮ?

            Ca va faire un an le mois prochain que j'ai quitte Microsoft.

    • [^] # Re: Pas compris le probleme....

      Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†1.

      C:\Users\nvidiatnt>bash

      Le TNT, parce que des fois, ça explose…

    • [^] # Re: Pas compris le probleme....

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†10.

      'bash' is not recognized as an internal or external command

      il est triste ton monde.

    • [^] # Re: Pas compris le probleme....

      Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†6.

      • [^] # Re: Pas compris le probleme....

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

        comme c'est beau …

      • [^] # Re: Pas compris le probleme....

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†-3.

        Voyons voir…

        Vulnerabilite Bash :
        - Tu mets ton attaque dans n'importe quelle variable et il sera execute quand bash se lance
        - bash est utilise en plusieurs endroits sous Unix/Linux en reponse a des requetes

        Le cas dans cmd.exe :
        - Il faut que ce soit une variable utilisee explicitement et d'une maniere particuliere par un script cmd.exe (un .bat qui cree des commandes a partir de cette variable ou qui l'affiche dans le cmd.exe)
        - A peu pres rien du tout ne lance un cmd.exe en remote sous Windows.

        Ben non, je rigoles toujours.

  • # exploit

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†0.

    je suis pas assez calé pour comprendre la vulnérabilité.

    ça fait quoi de plus que

    bash -c "echo vulnerable"
    ?

    • [^] # Re: exploit

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

      C'est fait en positionnant une variable.

      Tu peux déclencher un appel de code par une affectation. Et ça, c'est pas prévu. Donc en environnement qui autorise l'export de variable utilisateur autorise plus de chose que prévu.

      • [^] # Re: exploit

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†-2.

        et ? ça donne plus de droit qu'attendu ? je vois pas ce que ça fait de plus que bash -c "echo vulnerable".

    • [^] # Re: exploit

      Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†5.

      • [^] # Re: exploit

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        ok, ça commence à être concret.
        je me demande du coup pourquoi le dhclient utilise le champ "114" pour en faire une variable d'environnement du shell. La norme n'a pas l'air de dire de le faire…

        • [^] # Re: exploit

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†6.

          Parce que dhclient permet l’exécution de hooks (bien pratiques) et que pour transmettre un paquet d’informations (genre les routes, dns, etc…) à un hook les variables d’environnement sont un bon moyen.

          Et en dehors de DHCP tu as dans la norme CGI le fait que toutes les entêtes HTTP sont exportées en variables d’environnement.

      • [^] # Re: exploit

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†7.

        Testé ce matin.

        Sur un serveur DHCP classique, j'utilise l'option :
        option domain-name "() { :;}; echo 'plop' > /tmp/plop";

        Sur une Red-Hat EL5 sans SElinux et non patch√©e, un dhclient et /tmp/plop appara√ģt.

        Note : ne fonctionne pas sur RHEL6 : dhclient signale que le nom de domaine lui parait suspect ;-)

        • [^] # Re: exploit

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†6.

          Je regrette presque d'avoir mis à jour mes machines. Si je mets un eject, ça va m'ejecter le lecteur CD des machines à chaque mise à jour de l'IP ?

  • # De bonnes lectures

    Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†4.

    Maintenant que c'est un peu calmé, on peut lire quelques bons articles :

    • Une tr√®s bonne explication par le d√©couvreur de la faille lui-m√™me, ainsi qu‚Äôune discussion de ce que bash aurait d√Ľ faire pour ne pas nous mettre dans cette situation,
    • Une autre discussion technique sur comment r√©parer le probl√®me proprement, argumentant qu‚Äôajouter automatiquement toute fonction contenue dans une variable d‚Äôenvironnement quelconque √©tait de la folie,
    • Pour √©viter d‚Äôavoir cinquante mille PoC (Proof of Concept, une exploitation de la faille pour montrer qu‚Äôelle est r√©elle), un projet les regroupe toutes sur Github.

Suivre le flux des commentaires

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