Linux / unix : une très grave faille affecte le shell bash

  • Initiateur de la discussion Initiateur de la discussion el jadida
  • Date de début Date de début
@farid_h,
J ai lu ca hier, je voulais relayer l info mais j ai eu la flemme :)
Si tu veux rire, va lire d article de Slate a ce sujet.
C est tellement mal écrit que j ai cru que c était un hoax :)
En plus, sous pas mal de Linux, le shell par defaut n est pas bash sauf erreur.
Si je ne me trompe pas, j ai mis ma Mint sous bash pour incompatibilité avec quelques uns de mes scripts.
Ce que j aime bien, c est la complétion. Quand j utilisai FreeBSD, tcsh était frustrant pour ca, surtout quand on ne maitrise pas l arborescense du systeme.

http://www.slate.fr/story/92601/bash-nouveau-bug-pire-heartbleed
 
En plus, sous pas mal de Linux, le shell par defaut n est pas bash sauf erreur.
Houlala… malheureusement si, et à tel point que pour beaucoup de gens, en plus de confondre Linux et UNIX, confondent shell (le type d’application) et Bash, comme si le shell était toujours Bash.
 
Seulement les shell installés sur des machines au Maroc ? Peut‑être qu’il y a un ghost djin dedans et qu’il n’en fait qu’à sa tête

C’est drôle d’avoir posté sur ce sujet dans « Actualités Marocaines ». Pourquoi ?

qui se rappelle encore des faux-virus à l'ancienne en quelques lignes bash sur win :timide:
tout à coup votre pc devient possédé avec un écran à l'envers et le lecteur qui s'ouvre en permanence
:timide:
 
qui se rappelle encore des faux-virus à l'ancienne en quelques lignes bash sur win :timide:
tout à coup votre pc devient possédé avec un écran à l'envers et le lecteur qui s'ouvre en permanence
:timide:
A priori, sous Win c est des commandes DOS, pas bash :)
C est un peu le meme principe de lignes de commande, mais bash et les autres sont exclusivement pour les machines Unix :
Solaris, IBM, Hp_UX, Linux, FreeBSD, MacOSX etc
 
Houlala… malheureusement si, et à tel point que pour beaucoup de gens, en plus de confondre Linux et UNIX, confondent shell (le type d’application) et Bash, comme si le shell était toujours Bash.
Sauf erreur, c est pas dash sous Ubuntu ?
Les serveurs Ubuntu représentent 22% des serveur chez OVH, par exemple.
32% Debian.
http://www.ovh.com/ca/fr/a1264.systemes-exploitation-os-serveurs-dedies-ovh

Pour les autres Unix, a moins que ca ait changé, bash n est pas le shell par defaut.
 
Sauf erreur, c est pas dash sous Ubuntu ?
Pour moi c’était Bash, mais ça semble variable.

Dash, spécifique à Debian (Dash signifie Debian Almquist SHell) est plus primitif de Bash, et est utilisé par Debian pour les installations « légères et minimalistes » (qui ne le sont pas tant que ça, d’où mes guillemets).

ChangingShells (wiki.ubuntu.com)
ubuntu.com a dit:
Although bash, the default shell on many Debian based Linux distros like Ubuntu […]

Mais est aussi dit
DashAsBinSh (wiki.ubuntu.com)
ubuntu.com a dit:
In Ubuntu 6.10, the default system shell, /bin/sh, was changed to dash (the Debian Almquist Shell); previously it had been bash (the GNU Bourne-Again Shell).

Pourtant avec Ubuntu 12.04, c’était Bash.

Peut‑être une explication.

Code:
ls -l $(which sh)
Ça me dit
Code:
0 lrwxrwxrwx 1 root root 4 juin   8  2012 /bin/sh -> dash

Le Sh par défaut est bien Dash (Sh est un lien symbolique vers Dash), mais ça ne signifie pas que le shell par défaut le soit. Invoquer Sh, invoque Dash, mais ça n’empêche pas le shell par défaut d’être Bash… l’explication est peut‑être dans cette nuance.
 
Pour les autres Unix, a moins que ca ait changé, bash n est pas le shell par defaut.
Pas pour les BSD en tous cas (qui en plus sont sûrement plus des UNIX que ne l’est Linux).

2. Default Shell (freebsd.org)
freebsd.org a dit:
Linux® users are often surprised to find that Bash is not the default shell in FreeBSD. In fact, Bash is not even in the default installation. Instead, FreeBSD uses tcsh(1) as the default shell.

Ni pour Solaris
Selecting a Default Shell (docs.oracle.com)
docs.oracle.com a dit:
The Solaris 7 operating environment offers three shells:

Bourne shell, the default shell (/bin/sh)
C shell (/bin/csh)
Korn shell (/bin/ksh)

Et de même pour d’autres…

Bash est plus spécifique à Linux qu’aux UNIX en général.
 
Un veritable marathon de patching pour ce soir; je suis en train d'actualiser une ferme de 12,520 serveurs Linux. Heureusement que tout est bien automatise pour ca, et qu'actualiser /bin/bash ne cause aucune disruption (teste sur des systemes test). 4,237 / 12,520 actualises. pour l'instant...
 
Le Sh par défaut est bien Dash (Sh est un lien symbolique vers Dash), mais ça ne signifie pas que le shell par défaut le soit. Invoquer Sh, invoque Dash, mais ça n’empêche pas le shell par défaut d’être Bash… l’explication est peut‑être dans cette nuance.
Ce qui peut faire la difference, c est si des scripts appellent
#!/bin/sh
ou #!/bin/bash
Ca ne m etonnerai pas que certains utilisent le path complet.
A mon simple niveau de bricoleur, je ne me rappelle plus d exemple précis, mais j ai du etre explicite lors de l appel du shell dans certains scripts maison pour cause de compatibilité.
Exemple : des scripts écrits sous Ubuntu ne fonctionnaient plus sous Mint/Debian .
C est agacant :)
 
Un veritable marathon de patching pour ce soir; je suis en train d'actualiser une ferme de 12,520 serveurs Linux. Heureusement que tout est bien automatise pour ca, et qu'actualiser /bin/bash ne cause aucune disruption (teste sur des systemes test). 4,237 / 12,520 actualises. pour l'instant...
12520 ??? :)
Tu bosses chez un hébergeur ?
Je suppose que la plupart doivent etre des Debian. Ca traine pas les mises a jours importantes chez eux .
 
Zsh c’est plus mieux d’abord, nah!

Non, en vrai je connais pas Tcsh, j’ai jamais essayé.
Je prefere aussi zsh, mais dans les serveurs FreeBSD que j'administre, je prefere ne pas changer la default shell (tcsh pour utilisateurs et bourne shell pour les scripts). Pour l'instant, j'ai la chance de ne devoir actualiser qu'un nombre moyen de serveurs Linux, les FreeBSD auront leur tour quelques jours avant la publication de prochain security advisory. Pareil pour les autres Unix.
 
Je prefere aussi zsh, mais dans les serveurs FreeBSD que j'administre, je prefere ne pas changer la default shell (tcsh pour utilisateurs et bourne shell pour les scripts). Pour l'instant, j'ai la chance de ne devoir actualiser qu'un nombre moyen de serveurs Linux, les FreeBSD auront leur tour quelques jours avant la publication de prochain security advisory. Pareil pour les autres Unix.
Pourquoi prefere tu zsh ?
Pour l ecriture de scripts ? edit : lu trop vite pour les scripts.
Au quotidien, je n ai pas vu plus pratique que bash, esentiellement a cause de la complétion et la touche Tab.
J avoue sans honte etre fainéant :)
Je n ai pas trouvé de tableau comparatif pertinent sur les differents shells, avec leurs avantages et inconvénients.
 
Pourquoi prefere tu zsh ?
Pour l ecriture de scripts ? edit : lu trop vite pour les scripts.
Au quotidien, je n ai pas vu plus pratique que bash, esentiellement a cause de la complétion et la touche Tab.
J avoue sans honte etre fainéant :)
Je n ai pas trouvé de tableau comparatif pertinent sur les differents shells, avec leurs avantages et inconvénients.
Disons que pour les systemes Linux, les scripts ont perdu de l'importance depuis systemd (que j'aime pas vraiment, mais tout le monde va dans cette direction, on suit les masses, ca cause le moins de douleurs...)
 
Un veritable marathon de patching pour ce soir; je suis en train d'actualiser une ferme de 12,520 serveurs Linux. Heureusement que tout est bien automatise pour ca, et qu'actualiser /bin/bash ne cause aucune disruption […]
Tu connais un article plus sérieux que celui de Slate à ce sujet ? :rouge: Il y a réellement quelque chose ou pas ? Je n’utilise pas Bash, mais il est installé chez moi, il est l’interpréteur de quelques scripts, et c’est mon shell de login que je ne peux pas changer chez 1&1 (mais après je passe à zsh avec un `exec zsh` que j’ai ajouté à la fin de `.profile`).

La faille présente‑t‑elle un risque quand Bash est le shell de connexion et seulement ça ?
 
Tu connais un article plus sérieux que celui de Slate à ce sujet ? :rouge: Il y a réellement quelque chose ou pas ? Je n’utilise pas Bash, mais il est installé chez moi, il est l’interpréteur de quelques scripts, et c’est mon shell de login que je ne peux pas changer chez 1&1 (mais après je passe à zsh avec un `exec zsh` que j’ai ajouté à la fin de `.profile`).

La faille présente‑t‑elle un risque quand Bash est le shell de connexion et seulement ça ?
Cherches CVE-2014-6271 chez nist.gov.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
 
Tu connais un article plus sérieux que celui de Slate à ce sujet ? :rouge: Il y a réellement quelque chose ou pas ? Je n’utilise pas Bash, mais il est installé chez moi, il est l’interpréteur de quelques scripts, et c’est mon shell de login que je ne peux pas changer chez 1&1 (mais après je passe à zsh avec un `exec zsh` que j’ai ajouté à la fin de `.profile`).

La faille présente‑t‑elle un risque quand Bash est le shell de connexion et seulement ça ?
Si j ai bien compris, la faille existe quand bash est appellé. On s en fout de ton shell de connection
De plus, Apache a son propre user ...

cf http://www.bladi.info/threads/linux-unix-grave-faille-affecte-shell-bash.387109/#post-13170750
 
Ou, pour y repondre, oui, c'est tres serieux comme vuln.
Ils n’ont pas mis à jour, et je ne peux rien y faire, parce que c’est un serveur mutualisé.

Code:
bash --version
GNU bash, version 4.2.48(1)-ui-release (i486-pc-linux-gnu)
[bla‑bla GPL, le commerce c’est mal]

Et même après avoir fait les mise à jour en attente, pour Ubuntu c’est une version encore un peu plus ancienne:
Code:
bash --version
GNU bash, version 4.2.25(1)-release (i686-pc-linux-gnu)
[bla‑bla GPL, le commerce c’est mal]

Ben tant‑pis, je vais attendre les jours qui viennent (que faire d’autre ?) et lire à ce sujet pour savoir de quoi se méfier et savoir si quelque chose est déjà arrivé dans le passé sans que je ne m’en aperçoive.
 
Je voulais dire connexion SSH.
Il me semble que c est un autre pb.
Si on entre dans ta connection ssh, c est un pb de ssh.
Peu importe le shell, ca n intervient que apres l authentification.
Le risque du bug actuel est qu il peut etre appellé via des serveurs web Apache, forcément ouverts a l extérieur.
 
Retour
Haut