Faille dans Bash
Le
Dominique
Bonjour,
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
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
Dominique a écrit le 28/09/2014 06:53 :
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 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 -+-
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 ?
Pascal Hambourg wrote:
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
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.
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.
Nicolas George wrote:
Désolé, je n'avais pas compris le concept de "sous-shell" : je l'avais
compris comme le lancement de bash dans bash.
Ma réponse se voulait plus générale que le cas particulier de cette faille.
Cordialement
Dominique.
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).
needs-restarting dans yum-utils
Le 29/09/2014 21:33, Toxico Nimbus a écrit :
Merci beaucoup!
--
Stéphane