Faille de sécurité dans bash (mis à jour 12/10/2014)

Compte anonymisé · Le 27/09/2014, à 23:09

Salut à tous,
Bon, on en est ou de la faille ?
Merci

Perso, je suis avec bash 4.3.26 (ArchLinux).

jplemoine · Le 27/09/2014, à 23:09

CM63 a écrit :

Mais en revanche je ne comprends pas comment on peut outre-passer la nécessité de taper le mot de passe root

je pense que l'on ne peut pas mais par contre, il est possible que le "script" soit lancé par l'utilisateur root.

abelthorne · Le 27/09/2014, à 23:16

CM63 a écrit :

Je comprends qu'on outrepasse les droits d’exécution en définissant un script à la volée dans une variable environnement. Comme ce script n'est pas sur un fichier mais défini à la volée, je n'ai pas besoin de faire chmod +x . Mais en revanche je ne comprends pas comment on peut outre-passer la nécessité de taper le mot de passe root

On n'outrepasse rien du tout et on ne lance pas de script : la faille permet d'exécuter une commande arbitraire via certains logiciels serveurs tels qu'Apache (serveur web). Ça exécute donc la commande en question via l'utilisateur qui fait tourner le logiciel en question (par exemple pour Apache c'est www-data) et qui a quasiment les mêmes droits que root.

CM63 · Le 27/09/2014, à 23:20

Moi je suis comme vous, j'en reste sur le *** , cette faille existe probablement depuis l'Unix des années 80, l’ancêtre de Linux. Le shell était Bourne Shell, je crois, et on pouvait déjà définir des procédures en faisant a=$(bidule)

abelthorne · Le 27/09/2014, à 23:30

Oui, justement, le problème c'est qu'un petit malin a découvert qu'on pouvait passer des commandes à bash en balançant des entêtes HTML spéciales à Apache ou à un moteur CGI. Et potentiellement à d'autres logiciels serveurs qui interagissent avec bash.

Comme le signale un développeur dans un article posté plus haut, le problème vient surtout du fait que bash a été conçu à une époque où on ne se souciait pas énormément de la sécurité parce qu'on n'imaginait pas être dans un monde connecté où tout le monde aurait un accès Internet. De fait, c'est pas avec les patches mis en place ces jours-ci qu'on va le résoudre, c'est essentiellement un problème de conception. Et il y a vraisemblablement des tas de failles du même genre qui seront découvertes tôt ou tard dans d'autres logiciels, parce que de toute façon, tout est cassé.

Dernière modification par abelthorne (Le 27/09/2014, à 23:31)

Compte anonymisé · Le 27/09/2014, à 23:47

abelthorne a écrit :

Oui, justement, le problème c'est qu'un petit malin a découvert qu'on pouvait passer des commandes à bash en balançant des entêtes HTML spéciales à Apache ou à un moteur CGI. Et potentiellement à d'autres logiciels serveurs qui interagissent avec bash.
Comme le signale un développeur dans un article posté plus haut, le problème vient surtout du fait que bash a été conçu à une époque où on ne se souciait pas énormément de la sécurité parce qu'on n'imaginait pas être dans un monde connecté où tout le monde aurait un accès Internet. De fait, c'est pas avec les patches mis en place ces jours-ci qu'on va le résoudre, c'est essentiellement un problème de conception. Et il y a vraisemblablement des tas de failles du même genre qui seront découvertes tôt ou tard dans d'autres logiciels, parce que de toute façon, tout est cassé.

Dans l'idée, il faudrait bloquer les accès distant à mes serveurs ?
Perso, mon routeur bloque les accès par ssh et ftp.
D'autre chose à faire en plus des réglages habituels ?
Merci

Dernière modification par ignace72 (Le 27/09/2014, à 23:48)

F50 · Le 28/09/2014, à 05:32

C'est vraiment le boxon chez bash, re màj...!

Compte supprimé · Le 28/09/2014, à 05:44

Bon, en effet il est possible de récupérer /etc/passwd, mais puisqu'on ne peut pas changer d'utilisateur, ni devenir super-utilisateur ou root par cette faille apparemment, on ne peut pas récupérer /etc/shadow de cette façon. Tout va bien.

Ensuite www-data ne semble pas avoir les droit root, ni les droit du premier utilisateur, donc je ne vois pas comment, pour l'instant, www-data pourrait-il récupérer des fichiers ailleurs que ceux appartenant à www-data ? www-data n'est pas censé avoir les droits root !

Si quelqu'un peut y répondre.

En revanche, ce qui parait peut-être possible, mais peu probable, serait de lancer depuis www-data un programme distant de brute-force méthode, mais il semblerait qu'un bon mot de passe de 8 caractères hors dictionnaire a une durée de vie de un an … (cours d'informatiques de 2006 en MISMI).
Et à part le nombre de cœurs sur certains processeurs, leurs fréquences d'horloge restent sensiblement autour de 2 GHz comme en 2006 …
Donc un mot de passe à 9 caractères et on passe à 80 ans de résistance au brute-force méthode ? (dans un vrai mot de passe, on ne doit pas être limités à l'alphanumérique, mais on peut mettre les accents, et les signes de ponctuations …)

édit :
vous pouvez vérifier que toutes mes lignes dans /etc/passwd sont de la forme :

root:x:0:0:root:/root:/bin/bash

et qu'il ne manque pas un seul ':x:' en début de ligne après l'utilisateur.

Si vous pouvez retirer le x en début de ligne et sauvegarder les changements de ce fichier sans être root, alors vous êtes mal … mais seul root doit accéder à ce fichier. C'est ce que je faisais depuis une session live pour court-circuiter un mot de passe oublié à l'époque où je ne savais pas utiliser chroot avec les sessions live … pour changer le mot de passe des ordinateurs dont les gens avaient mis un mot de passe qu'ils avaient oublié.

Sinon :

lludovic@ludovic-G41MT-S2PT:~$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1807 août   5 14:09 /etc/passwd
ludovic@ludovic-G41MT-S2PT:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
messagebus:x:102:105::/var/run/dbus:/bin/false
colord:x:103:108:colord colour management daemon,,,:/var/lib/colord:/bin/false
lightdm:x:104:111:Light Display Manager:/var/lib/lightdm:/bin/false
avahi-autoipd:x:105:117:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false
avahi:x:106:118:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
usbmux:x:107:46:usbmux daemon,,,:/home/usbmux:/bin/false
kernoops:x:108:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false
pulse:x:109:119:PulseAudio daemon,,,:/var/run/pulse:/bin/false
rtkit:x:110:121:RealtimeKit,,,:/proc:/bin/false
hplip:x:111:7:HPLIP system user,,,:/var/run/hplip:/bin/false
saned:x:112:122::/home/saned:/bin/false
ludovic:x:1000:1000:Ludovic,,,:/home/ludovic:/bin/bash
statd:x:113:65534::/var/lib/nfs:/bin/false
timidity:x:114:124:TiMidity++ MIDI sequencer service:/etc/timidity:/bin/false
munge:x:115:125::/home/munge:/bin/false
postfix:x:116:127::/var/spool/postfix:/bin/false
gdm:x:117:129:Gnome Display Manager:/var/lib/gdm:/bin/false
ludovic@ludovic-G41MT-S2PT:~$ echo "#test" >> /etc/passwd
bash: /etc/passwd: Permission non accordée

ludovic@ludovic-G41MT-S2PT:~$ echo "#test" >> /etc/passwd
bash: /etc/passwd: Permission non accordée

Tout va bien

Dernière modification par Compte supprimé (Le 28/09/2014, à 06:08)

Compte anonymisé · Le 28/09/2014, à 05:55

Donc le mieux, c'est un mot de passe avec un clavier bépo

Brunod · Le 28/09/2014, à 08:22

Je n'ai pas lu les 8 pages, mais ça a l'air de faire poupée russe ce problème, notamment au niveau des patch.
Pour colmater le problème en attendant une solution "définitive":
- peut-on remplacer bash par un autre shell et éviter la faille ?
- peut-on configurer les accès avec le fire-wall pour bloquer ce problème des fuites ?
- avez-vous d'autres idées/solutions ?
Merci,
BD

bruno · Le 28/09/2014, à 08:58

Je pense que les correctifs vont continuer d’arriver car la découverte de cette faille à incité bon nombre de développeurs à se pencher sur le code de Bash.

Quelques éléments de réponse.

Ceux qui ont été publiés permettent de combler la faille découverte.
Debian et Ubuntu utilisent Dash par défaut qui n'est pas vulnérable (voir ls -l /bin/sh)
Il est tout a fait possible de changer de shell interactif pour les utilisateurs standard (y compris root). Je recommande zsh qui extrêmement pratique et puissant. Ex changer les shell de toto :

sudo usmermod -s /bin/zsh toto

EDIT : évidemment avant de faire cela il faut avoir installé zsh…

Dernière modification par bruno (Le 28/09/2014, à 09:22)

Brunod · Le 28/09/2014, à 09:15

bruno a écrit :

...
Debian et Ubuntu utilisent Dash par défaut qui n'est pas vulnérable (voir ls -l /bin/sh)
Il est tout a fait possible de changer de shell interactif pour les utilisateurs standard (y compris root). Je recommande zsh qui extrêmement pratique et puissant. Ex changer les shell de toto :
sudo usmermod -s /bin/zsh toto

Merci Bruno,
Mais selon ce que j'ai compris de Shellshock, si bash est substitué par un autre shell, le problème n'est-il pas reproductible sur cet autre shell ??
Brunod

bruno · Le 28/09/2014, à 09:21

Je n'ai pas de certitude là dessus, mais il semble bien que la faille soit due à une à une capacité bien spécifique au Bash. D'ailleurs les diverses commandes que l'on peut trouver sur le web pour tester la faille échouent toutes sous Dash ou sous ZSH.

Au vu du nombre de messages dans ce fil, j'aimerai repréciser que cette faille doit surtout inquiéter les administrateurs système. Les utilisateurs de machines personnelles qui n'hébergent pas de services ouverts vers l'extérieur (en particulier un serveur Web avec CGI ou dans une moindre mesure un accès ssh) n'ont pas à s'en inquiéter outre mesure. Il suffit de continuer à faire ses mises à jour régulièrement.

Dernière modification par bruno (Le 28/09/2014, à 09:29)

Brunod · Le 28/09/2014, à 09:27

@bruno : ok, merci
BD

Caribou22 · Le 28/09/2014, à 09:29

Bonjour,

La plupart des messages ici sont une langue encore étrangère pour moi hélas. J'aurai besoin de quelques explications concrètes :
- Les mises à jour habituelles vont-elles résoudre le problème pour les utilisateurs lambda ?
- Y a t'il des risques pour quelqu'un qui n'utilise pas son ordinateur comme serveur ?
- Les premières installations faites dans mon entourage étaient et sont depuis en 13.04. Est-ce que cette faille accentue les risques ? (Est-ce que je dois aller les mettre à jour d'urgence en d'autres termes ?)
- Les risques évoqués dans mes deux premières questions, quels sont-ils exactement ?

Merci d'avance.

bruno · Le 28/09/2014, à 09:32

Voir mon message en #190
Pour les deux premières questions :
Oui
Non

jplemoine · Le 28/09/2014, à 10:00

Caribou22 a écrit :

- Les mises à jour habituelles vont-elles résoudre le problème pour les utilisateurs lambda ?

oui

Caribou22 a écrit :

- Y a t'il des risques pour quelqu'un qui n'utilise pas son ordinateur comme serveur ?

non

Caribou22 a écrit :

- Les premières installations faites dans mon entourage étaient et sont depuis en 13.04. Est-ce que cette faille accentue les risques ? (Est-ce que je dois aller les mettre à jour d'urgence en d'autres termes ?)

S'ils sont toujours en 13.04, il faudrait mieux les passer rapidement en 14.04 (quitte à passer sur une variante si ordi trop faible) : la 13.04 n'est plus maintenue.

Caribou22 a écrit :

- Les risques évoqués dans mes deux premières questions, quels sont-ils exactement ?

je ne sais pas mais peu de (voire aucun) risques pour le commun des mortels (si ni d'Apache installé, si ssh serveur : installation explicite pas par défaut).

tristan76 · Le 28/09/2014, à 10:07

Etrange non ? cette réponse du bash à jour...

jplemoine · Le 28/09/2014, à 10:14

Non. C'est la réponse "normale" depuis un patch d'hier ou avant-hier...
En fait, il y a eu un premier patch (patch à chaud : dev rapide) qui comblait la faille de sécurité mais ensuite, il y en a eu plusieurs autres.
Maintenant, c'est la réponse.
Pour résumé :
- si ça dit vulnerable : pas bon
- si ça met une erreur : la faille est comblée mais le système n'est pas à jour
- si ça met que "this is a test" : le système est à jour et la faille est comblée.

Dernière modification par jplemoine (Le 28/09/2014, à 10:15)

tristan76 · Le 28/09/2014, à 10:17

alors merci
Nesthib : Pourrais tu préciser la nature du "retour" dans Bash en haut de page...?

jplemoine · Le 28/09/2014, à 10:20

Je pense qu'il faut reprendre entièrement le bandeau : le rouge et l'écriture en gros n'est peut-être plus nécessaire..
Et oui, donner le résumé des retours (un peu comme j'ai fait ci-dessus) serait une bonne idée.

Compte supprimé · Le 28/09/2014, à 10:29

Apparemment, un premier malware nommé Bash Lite serait né pour l'occasion... Gare aux administrateurs réseaux qui tarderaient dans les mises à jour...
Voir ici ou ici

Loupus11 · Le 28/09/2014, à 10:39

jplemoine a écrit :

Non. C'est la réponse "normale" depuis un patch d'hier ou avant-hier...
En fait, il y a eu un premier patch (patch à chaud : dev rapide) qui comblait la faille de sécurité mais ensuite, il y en a eu plusieurs autres.
Maintenant, c'est la réponse.
Pour résumé :
- si ça dit vulnerable : pas bon
- si ça met une erreur : la faille est comblée mais le système n'est pas à jour
- si ça met que "this is a test" : le système est à jour et la faille est comblée.

Ok merci

Je me sens bien mieux!!

dais@dais-H61H2-LM3:~$ sudo apt-get upgrade bash
[sudo] password for dais: 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
bash est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
dais@dais-H61H2-LM3:~$ sudo apt full-upgrade bash
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
bash est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
dais@dais-H61H2-LM3:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test


Cool :cool:

Dernière modification par Loupus11 (Le 28/09/2014, à 10:40)

abelthorne · Le 28/09/2014, à 11:12

L_d_v_c@ a écrit :

Ensuite www-data ne semble pas avoir les droit root, ni les droit du premier utilisateur, donc je ne vois pas comment, pour l'instant, www-data pourrait-il récupérer des fichiers ailleurs que ceux appartenant à www-data ? www-data n'est pas censé avoir les droits root !
En revanche, ce qui parait peut-être possible, mais peu probable, serait de lancer depuis www-data un programme distant de brute-force méthode, mais il semblerait qu'un bon mot de passe de 8 caractères hors dictionnaire a une durée de vie de un an … (cours d'informatiques de 2006 en MISMI).

Le problème de cette faille n'est pas que tu puisses te faire piquer ton mot de passe root ou des photos de vacances stockées dans ton dossier perso. C'est surtout qu'elle peut permettre de manipuler facilement les fichiers d'un serveur web : ça devient facile de balancer des sites de phishing sur un serveur, d'avoir accès aux données utilisateurs d'une base de données, etc. Tout ce que le serveur web a le droit de faire, quoi. Habituellement, pour ce genre d'opération, il faut exploiter une faille dans une appli web et donc tomber sur la bonne combinaison de bugs non corrigés ; là, c'est une faille au cœur du système.

Compte supprimé · Le 28/09/2014, à 11:17

Je suis parti sur une piste incomplète, s'il a eu attaque, et modification du système, on ne peut pas le déceler depuis la machine subissant la faille.

L_d_v_c@ a écrit :

…
ludovic@ludovic-G41MT-S2PT:~$ echo "#test" >> /etc/passwd
bash: /etc/passwd: Permission non accordée
ludovic@ludovic-G41MT-S2PT:~$ echo "#test" >> /etc/passwd
bash: /etc/passwd: Permission non accordée
Tout va bien

«L'absence de preuve n'est pas la preuve de l'absence.»

Donc non, on ne peut pas savoir, il faut remettre FreeBSD (ou autre *BSD) et analyser le système GNU/Linux pour bien faire … on espérant que la faille bash -c ne touche pas BSD …
Mais la seule barrière qui reste est l'impossibilité normale de devenir root depuis www-data, et à moins que les informaticiens ne prouvent l'impossibilité formelle après la lecture de tous les sources, ça patche comme ça peut …

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#176 Le 27/09/2014, à 23:09

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#177 Le 27/09/2014, à 23:09

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#178 Le 27/09/2014, à 23:16

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#179 Le 27/09/2014, à 23:20

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#180 Le 27/09/2014, à 23:30

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#181 Le 27/09/2014, à 23:47

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#182 Le 28/09/2014, à 05:32

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#183 Le 28/09/2014, à 05:44

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#184 Le 28/09/2014, à 05:55

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#185 Le 28/09/2014, à 08:22

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#186 Le 28/09/2014, à 08:58

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#187 Le 28/09/2014, à 09:15

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#188 Le 28/09/2014, à 09:21

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#189 Le 28/09/2014, à 09:27

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#190 Le 28/09/2014, à 09:29

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#191 Le 28/09/2014, à 09:32

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#192 Le 28/09/2014, à 10:00

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#193 Le 28/09/2014, à 10:07

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#194 Le 28/09/2014, à 10:14

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#195 Le 28/09/2014, à 10:17

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#196 Le 28/09/2014, à 10:20

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#197 Le 28/09/2014, à 10:29

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#198 Le 28/09/2014, à 10:39

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#199 Le 28/09/2014, à 11:12

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

#200 Le 28/09/2014, à 11:17

Re : Faille de sécurité dans bash (mis à jour 12/10/2014)

Pied de page des forums