Journal Mets à jour ton bash. Maintenant.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
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 septembre 2014 à 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 septembre 2014 à 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.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 8.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # 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 septembre 2014 à 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 septembre 2014 à 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 septembre 2014 à 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 septembre 2014 à 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 septembre 2014 à 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 septembre 2014 à 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.

      le danger ? ;)

      CMD.EXE

      http://al.howardknight.net/msgid.cgi?ID=141224474700

      • [^] # 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.

      quoi de plus

      Un exemple parlant :
      https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

      • [^] # 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.