Le 26/09/2014 11:16, a écrit :On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 26/09/2014 11:16, andre_debian@numericable.fr a écrit :
On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.
Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5425303A.4010609@freeatome.com
Le 26/09/2014 11:16, a écrit :On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 26/09/2014 11:16, a écrit :On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 26/09/2014 11:16, andre_debian@numericable.fr a écrit :
On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.
Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5425303A.4010609@freeatome.com
Le 26/09/2014 11:16, a écrit :On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:env x='() { :;}; echo vulnerable' bash -c 'echo hello'
J'ai upgradé bash et relancé, tapé la commande ci-dessus
et j'ai ce message de warning :
"bash: warning: x: ignoring function definition attempt
bash: erreur lors de l'import de la définition de fonction pour  « x »
hello"
il faut refaire l'upgrade une fois. il y a une nouvelle upgrade de bash c e
matin, il devrait afficher que hello sans erreur.Quid ?
André
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash…
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :
Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash…
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash…
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
mais il me semble que si l'on prend l'exemple d'un serveur
Web, ça n'est pas simple de pouvoir exploiter cette faible
à distance. Parce qu'il faut déjà que le serveur web soit
amené à lancer un bash ce qui me semble pas toujours le
cas (mais il paraît que ça peut arriver avec du cgi par
exemple) mais surtout il faut que l'attaquant arrive à
distance à faire en sorte qu'une nouvelle variable
d'environnement soit définie au moment où le bash
s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
mais il me semble que si l'on prend l'exemple d'un serveur
Web, ça n'est pas simple de pouvoir exploiter cette faible
à distance. Parce qu'il faut déjà que le serveur web soit
amené à lancer un bash ce qui me semble pas toujours le
cas (mais il paraît que ça peut arriver avec du cgi par
exemple) mais surtout il faut que l'attaquant arrive à
distance à faire en sorte qu'une nouvelle variable
d'environnement soit définie au moment où le bash
s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
mais il me semble que si l'on prend l'exemple d'un serveur
Web, ça n'est pas simple de pouvoir exploiter cette faible
à distance. Parce qu'il faut déjà que le serveur web soit
amené à lancer un bash ce qui me semble pas toujours le
cas (mais il paraît que ça peut arriver avec du cgi par
exemple) mais surtout il faut que l'attaquant arrive à
distance à faire en sorte qu'une nouvelle variable
d'environnement soit définie au moment où le bash
s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
Je vais peut-être dire des bêtises (auquel cas
je serais ravi d'avoir des explications) mais il me semble que si
l'on prend l'exemple d'un serveur Web, ça n'est pas simple de pouvoir
exploiter cette faible à distance. Parce qu'il faut déjà que le serveur
web soit amené à lancer un bash ce qui me semble pas toujours le cas
(mais il paraît que ça peut arriver avec du cgi par exemple) mais
surtout il faut que l'attaquant arrive à distance à faire en sorte
qu'une nouvelle variable d'environnement soit définie au moment où
le bash s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
Je vais peut-être dire des bêtises (auquel cas
je serais ravi d'avoir des explications) mais il me semble que si
l'on prend l'exemple d'un serveur Web, ça n'est pas simple de pouvoir
exploiter cette faible à distance. Parce qu'il faut déjà que le serveur
web soit amené à lancer un bash ce qui me semble pas toujours le cas
(mais il paraît que ça peut arriver avec du cgi par exemple) mais
surtout il faut que l'attaquant arrive à distance à faire en sorte
qu'une nouvelle variable d'environnement soit définie au moment où
le bash s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Perso, même si c'est vraiment une grosse faille, ça me semble moins
grave que Heartbleed.
Je vais peut-être dire des bêtises (auquel cas
je serais ravi d'avoir des explications) mais il me semble que si
l'on prend l'exemple d'un serveur Web, ça n'est pas simple de pouvoir
exploiter cette faible à distance. Parce qu'il faut déjà que le serveur
web soit amené à lancer un bash ce qui me semble pas toujours le cas
(mais il paraît que ça peut arriver avec du cgi par exemple) mais
surtout il faut que l'attaquant arrive à distance à faire en sorte
qu'une nouvelle variable d'environnement soit définie au moment où
le bash s'exécute sur le serveur et ça, ça me semble pas évident à
distance.
En effet, la faille s'exploite en définissant une variable
d'environnement qui fera partie du processus du bash. Mais si un
attaquant arrive à faire cela, alors sans même que cette faille existe,
ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
déjà mettre un peu la pagaille, non ?
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :
> Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
> empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux qui utiliseraient explicitement « /bin/bash »
seraient impactés.
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :
> Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
> empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux qui utiliseraient explicitement « /bin/bash »
seraient impactés.
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :
> Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh" vers dash
> empêche ce type d'attaque ou limite l'attaque à certain CGI mal écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux qui utiliseraient explicitement « /bin/bash »
seraient impactés.
On Fri, Sep 26, 2014 at 11:10:53AM +0200, Francois Lafont wrote:
> Perso, même si c'est vraiment une grosse faille, ça me semble moins
> grave que Heartbleed.
Ça se discute, les effets n'étant pas le même...
Par exemple, ici il va falloir mettre à jour les serveurs:
c'est lourd, mais on sait faire. Par conter, ne pas mettre à
jour, c'est laisser son serveur ouvert à 4 vents.
Avec Heartbleed, il fallait demander aux utilisateurs de
changer leurs mots de passe, recréer des certificats etc...
beaucoup plus d'impact opérationel au final.
La définition de CGI, c'est que le serveur Web communique au
script les paramètres de la communication (URL, query, IP
source, ce genre de choses) par l'intermédiaire de variables
d'environnements (REQUEST_URI, si ma mémoire est bonne).
Donc tout script CGI a des variables d'environnements qui
sont au final définies par le client.
Donc tout script CGI bash est exploitable trivialement.
On Fri, Sep 26, 2014 at 11:10:53AM +0200, Francois Lafont wrote:
> Perso, même si c'est vraiment une grosse faille, ça me semble moins
> grave que Heartbleed.
Ça se discute, les effets n'étant pas le même...
Par exemple, ici il va falloir mettre à jour les serveurs:
c'est lourd, mais on sait faire. Par conter, ne pas mettre à
jour, c'est laisser son serveur ouvert à 4 vents.
Avec Heartbleed, il fallait demander aux utilisateurs de
changer leurs mots de passe, recréer des certificats etc...
beaucoup plus d'impact opérationel au final.
La définition de CGI, c'est que le serveur Web communique au
script les paramètres de la communication (URL, query, IP
source, ce genre de choses) par l'intermédiaire de variables
d'environnements (REQUEST_URI, si ma mémoire est bonne).
Donc tout script CGI a des variables d'environnements qui
sont au final définies par le client.
Donc tout script CGI bash est exploitable trivialement.
On Fri, Sep 26, 2014 at 11:10:53AM +0200, Francois Lafont wrote:
> Perso, même si c'est vraiment une grosse faille, ça me semble moins
> grave que Heartbleed.
Ça se discute, les effets n'étant pas le même...
Par exemple, ici il va falloir mettre à jour les serveurs:
c'est lourd, mais on sait faire. Par conter, ne pas mettre à
jour, c'est laisser son serveur ouvert à 4 vents.
Avec Heartbleed, il fallait demander aux utilisateurs de
changer leurs mots de passe, recréer des certificats etc...
beaucoup plus d'impact opérationel au final.
La définition de CGI, c'est que le serveur Web communique au
script les paramètres de la communication (URL, query, IP
source, ce genre de choses) par l'intermédiaire de variables
d'environnements (REQUEST_URI, si ma mémoire est bonne).
Donc tout script CGI a des variables d'environnements qui
sont au final définies par le client.
Donc tout script CGI bash est exploitable trivialement.
Ou ceux qui exécutent un programme menant indirectement à l'exécution
de bash, puisque l'environnement est hérité.
grep /bin/bash /bin/* /usr/bin/*
peut donner une idée de ce qui ne doit pas être exécuté (directement
ou indirectement).
Ou ceux qui exécutent un programme menant indirectement à l'exécution
de bash, puisque l'environnement est hérité.
grep /bin/bash /bin/* /usr/bin/*
peut donner une idée de ce qui ne doit pas être exécuté (directement
ou indirectement).
Ou ceux qui exécutent un programme menant indirectement à l'exécution
de bash, puisque l'environnement est hérité.
grep /bin/bash /bin/* /usr/bin/*
peut donner une idée de ce qui ne doit pas être exécuté (directement
ou indirectement).
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh"
vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal
écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :
Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh"
vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal
écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/
20140926094405.GA16795@sebian.nob900.homeip.net
Bonjour,
Le vendredi 26 septembre 2014 à 11:03, Frédéric MASSOT a écrit :Sur un serveur web, est-ce que le fait d'avoir le lien "/bin/sh"
vers dash
empêche ce type d'attaque ou limite l'attaque à certain CGI mal
écrit ?
Si tous les CGI utilisent « /bin/sh », alors pas de problème. En
revanche, ceux
qui utiliseraient explicitement « /bin/bash » seraient impactés.
La meilleure parade reste de toute façon la mise-à-jour de Bash
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/