Comme tout le monde, j'ai appris qu'il y avait une faille de sécurité
dans Bash. Je n'en ai pas bien compris les tenants et les aboutissants
mais Ubuntu me propose cette MAJ (que j'ai installée) :
****************************************
Cette mise à jour a été diffusée le 26/09/2014 15:27
* SECURITY UPDATE: out-of-bounds memory access
- debian/patches/CVE-2014-718x.diff: guard against overflow and fix
off-by-one in bash/parse.y.
- CVE-2014-7186
- CVE-2014-7187
* SECURITY IMPROVEMENT: use prefixes and suffixes for function exports
- debian/patches/variables-affix.diff: add prefixes and suffixes in
bash/variables.c.
****************************************
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Je vous remercie et vous souhaite un beau et bon dimanche,
--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
yamo'
Salut,
Dominique a écrit le 28/09/2014 06:53 :
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou seulement la deuxième) mises à jour de bash et redémarrer tout ce qui utilise bash! checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
* checkrestart est contenu dans debian-goodies.
-- Stéphane <http://pasdenom.info/fortune/?> L'une des plus grandes sagesses en l'art militaire, c'est de ne pas pousser son ennemi au désespoir. -+- Michel de Montaigne, essais -+-
Salut,
Dominique a écrit le 28/09/2014 06:53 :
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou
seulement la deuxième) mises à jour de bash et redémarrer tout ce qui
utilise bash!
checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
* checkrestart est contenu dans debian-goodies.
--
Stéphane <http://pasdenom.info/fortune/?>
L'une des plus grandes sagesses en l'art militaire,
c'est de ne pas pousser son ennemi au désespoir.
-+- Michel de Montaigne, essais -+-
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou seulement la deuxième) mises à jour de bash et redémarrer tout ce qui utilise bash! checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
* checkrestart est contenu dans debian-goodies.
-- Stéphane <http://pasdenom.info/fortune/?> L'une des plus grandes sagesses en l'art militaire, c'est de ne pas pousser son ennemi au désespoir. -+- Michel de Montaigne, essais -+-
Nicolas George
yamo' , dans le message <m08feb$un8$, a écrit :
et redémarrer tout ce qui utilise bash!
Non. La faille se trouve au niveau de la gestion de l'environnement au démarrage, donc un bash déjà en train de tourner n'est plus vulnérable.
yamo' , dans le message <m08feb$un8$1@usenet.pasdenom.info>, a écrit :
et redémarrer tout ce qui utilise bash!
Non. La faille se trouve au niveau de la gestion de l'environnement au
démarrage, donc un bash déjà en train de tourner n'est plus vulnérable.
Non. La faille se trouve au niveau de la gestion de l'environnement au démarrage, donc un bash déjà en train de tourner n'est plus vulnérable.
Même lors du lancement d'un sous-shell ?
Dominique MICOLLET
Bonjour,
Pascal Hambourg wrote:
Même lors du lancement d'un sous-shell ?
Théoriquement, non. Pratiquement, je ne suis pas certain que le cache noyau linux aura été nettoyé par la mise à jour : par conséquent, le code exécuté par le sous- shell peut être celui qui a été mis en cache.
En tout cas, le "sur-shell" reste impacté par la faille tant qu'il n'est pas arrêté.
Cordialement
Dominique
Bonjour,
Pascal Hambourg wrote:
Même lors du lancement d'un sous-shell ?
Théoriquement, non.
Pratiquement, je ne suis pas certain que le cache noyau linux aura été
nettoyé par la mise à jour : par conséquent, le code exécuté par le sous-
shell peut être celui qui a été mis en cache.
En tout cas, le "sur-shell" reste impacté par la faille tant qu'il n'est pas
arrêté.
Théoriquement, non. Pratiquement, je ne suis pas certain que le cache noyau linux aura été nettoyé par la mise à jour : par conséquent, le code exécuté par le sous- shell peut être celui qui a été mis en cache.
En tout cas, le "sur-shell" reste impacté par la faille tant qu'il n'est pas arrêté.
Cordialement
Dominique
Nicolas George
Pascal Hambourg , dans le message <m0bavc$2lqu$, a écrit :
Même lors du lancement d'un sous-shell ?
Intuitivement je dirais non, car le sous-shell n'est qu'une notation pour un fork() explicite ; on n'appelle pas l'_init des bibliothèques partagées après un fork(). Mais c'est une bonne question et ça mérite vérification :
$ HACK_ME="() { :; }; echo Bang you are dead." ./bash-4.2+dfsg-0.1 -c true Bang you are dead.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead."; export HACK_ME; echo I am not dead.; ( echo I am not dead either. )' I am not dead. I am not dead either.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead."; export HACK_ME; echo I am not dead.; ( echo I am not dead either. ); ./bash-4.2+dfsg-0.1 -c true' I am not dead. I am not dead either. Bang you are dead.
Donc pas en cas de sous-shell.
Pascal Hambourg , dans le message <m0bavc$2lqu$1@saria.nerim.net>, a
écrit :
Même lors du lancement d'un sous-shell ?
Intuitivement je dirais non, car le sous-shell n'est qu'une notation pour un
fork() explicite ; on n'appelle pas l'_init des bibliothèques partagées
après un fork(). Mais c'est une bonne question et ça mérite vérification :
$ HACK_ME="() { :; }; echo Bang you are dead." ./bash-4.2+dfsg-0.1 -c true
Bang you are dead.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead.";
export HACK_ME; echo I am not dead.; ( echo I am not dead either. )'
I am not dead.
I am not dead either.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead.";
export HACK_ME; echo I am not dead.; ( echo I am not dead either. );
./bash-4.2+dfsg-0.1 -c true'
I am not dead.
I am not dead either.
Bang you are dead.
Pascal Hambourg , dans le message <m0bavc$2lqu$, a écrit :
Même lors du lancement d'un sous-shell ?
Intuitivement je dirais non, car le sous-shell n'est qu'une notation pour un fork() explicite ; on n'appelle pas l'_init des bibliothèques partagées après un fork(). Mais c'est une bonne question et ça mérite vérification :
$ HACK_ME="() { :; }; echo Bang you are dead." ./bash-4.2+dfsg-0.1 -c true Bang you are dead.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead."; export HACK_ME; echo I am not dead.; ( echo I am not dead either. )' I am not dead. I am not dead either.
$ ./bash-4.2+dfsg-0.1 -c 'HACK_ME="() { :; }; echo Bang you are dead."; export HACK_ME; echo I am not dead.; ( echo I am not dead either. ); ./bash-4.2+dfsg-0.1 -c true' I am not dead. I am not dead either. Bang you are dead.
Donc pas en cas de sous-shell.
Nicolas George
Dominique MICOLLET , dans le message <542938fb$0$12775$, a écrit :
Pratiquement, je ne suis pas certain que le cache noyau linux aura été nettoyé par la mise à jour : par conséquent, le code exécuté par le sous- shell peut être celui qui a été mis en cache.
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un exécutable pendant son exécution.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Dominique MICOLLET , dans le message
<542938fb$0$12775$426a74cc@news.free.fr>, a écrit :
Pratiquement, je ne suis pas certain que le cache noyau linux aura été
nettoyé par la mise à jour : par conséquent, le code exécuté par le sous-
shell peut être celui qui a été mis en cache.
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas
l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un
exécutable pendant son exécution.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est
exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Dominique MICOLLET , dans le message <542938fb$0$12775$, a écrit :
Pratiquement, je ne suis pas certain que le cache noyau linux aura été nettoyé par la mise à jour : par conséquent, le code exécuté par le sous- shell peut être celui qui a été mis en cache.
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un exécutable pendant son exécution.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Dominique MICOLLET
Bonjour,
Nicolas George wrote:
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un exécutable pendant son exécution.
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais compris comme le lancement de bash dans bash.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Ma réponse se voulait plus générale que le cas particulier de cette faille.
Cordialement
Dominique.
Bonjour,
Nicolas George wrote:
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas
l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un
exécutable pendant son exécution.
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais
compris comme le lancement de bash dans bash.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est
exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Ma réponse se voulait plus générale que le cas particulier de cette faille.
Le code exécuté par le sous-shell SERA celui de l'original, ça ne fait pas l'ombre d'un doute. Encore heureux, ce serait dramatique de changer un exécutable pendant son exécution.
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais compris comme le lancement de bash dans bash.
Mais c'est complètement non-pertinent, car la partie vulnérable n'est exécutée qu'au lancement global, pas lors du dédoublement en sous-shell.
Ma réponse se voulait plus générale que le cas particulier de cette faille.
Cordialement
Dominique.
Nicolas George
Dominique MICOLLET , dans le message <54294492$0$2137$, a écrit :
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais compris comme le lancement de bash dans bash.
Dans le cas du lancement d'un second bash par bash, il ne fait là encore aucun doute que ce sera le nouveau qui sera exécuté.
Il peut y avoir un doute à ce sujet dans le cas d'un client NFS si la mise à jour a été faite à l'arrache sur le serveur, mais c'est un problème inhérent à NFS (et qui ne concerne que les mises à jour faites à l'arrache, comme dit plus haut).
Dominique MICOLLET , dans le message
<54294492$0$2137$426a74cc@news.free.fr>, a écrit :
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais
compris comme le lancement de bash dans bash.
Dans le cas du lancement d'un second bash par bash, il ne fait là encore
aucun doute que ce sera le nouveau qui sera exécuté.
Il peut y avoir un doute à ce sujet dans le cas d'un client NFS si la mise à
jour a été faite à l'arrache sur le serveur, mais c'est un problème inhérent
à NFS (et qui ne concerne que les mises à jour faites à l'arrache, comme dit
plus haut).
Dominique MICOLLET , dans le message <54294492$0$2137$, a écrit :
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais compris comme le lancement de bash dans bash.
Dans le cas du lancement d'un second bash par bash, il ne fait là encore aucun doute que ce sera le nouveau qui sera exécuté.
Il peut y avoir un doute à ce sujet dans le cas d'un client NFS si la mise à jour a été faite à l'arrache sur le serveur, mais c'est un problème inhérent à NFS (et qui ne concerne que les mises à jour faites à l'arrache, comme dit plus haut).
Toxico Nimbus
Le 28/09/2014 10:04, yamo' a écrit :
Salut,
Dominique a écrit le 28/09/2014 06:53 :
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou seulement la deuxième) mises à jour de bash et redémarrer tout ce qui utilise bash! checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
needs-restarting dans yum-utils
* checkrestart est contenu dans debian-goodies.
Le 28/09/2014 10:04, yamo' a écrit :
Salut,
Dominique a écrit le 28/09/2014 06:53 :
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou
seulement la deuxième) mises à jour de bash et redémarrer tout ce qui
utilise bash!
checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
Est-ce qu'elle corrige la faille annoncée dans la presse ?
Sur debian, centos et sûrement ubuntu il faut passer les deux (ou seulement la deuxième) mises à jour de bash et redémarrer tout ce qui utilise bash! checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
needs-restarting dans yum-utils
* checkrestart est contenu dans debian-goodies.
yamo'
Salut,
Le 29/09/2014 21:33, Toxico Nimbus a écrit :
checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
needs-restarting dans yum-utils
>* checkrestart est contenu dans debian-goodies.
Merci beaucoup! -- Stéphane
Salut,
Le 29/09/2014 21:33, Toxico Nimbus a écrit :
checkrestart* peut aider (je ne trouve pas l'équivalent sur centos).
