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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
yamo'
Le #26312076
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 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
Le #26312082
yamo' , dans le message
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.
Pascal Hambourg
Le #26312182
Nicolas George a écrit :
yamo' , dans le message
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.



Même lors du lancement d'un sous-shell ?
Dominique MICOLLET
Le #26312196
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
Nicolas George
Le #26312205
Pascal Hambourg , dans le message é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
Le #26312204
Dominique MICOLLET , dans le message
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
Le #26312209
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.
Nicolas George
Le #26312213
Dominique MICOLLET , dans le message
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 #26312279
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.

yamo'
Le #26312760
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
Publicité
Poster une réponse
Anonyme