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

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

abelthorne a écrit :

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.

Si on peut modifier les fichiers du serveur web qui distribuerait des versions de sources ou des distributions GNU/Linux …
Piquer le mot de passe, on s'en fiche, mais si on trouve le mot de passe root, donc l'accès root, on peut installer chevaux de Troie et compagnie, mais si quelqu'un ou un État installe des VMBR alors il faut tout reprendre car il est impossible de détecter les VMBR … et il est possible de faire des VMBR multiplateformes et multi-OS pour ces gens-là … (il suffit d'écrire des VMBR métamorphiques)

Si un système est infecté, et que tu compiles des sources vérifiés, l'exécutable n'est pas forcément ce qu'il devrait être. Car GCC peut être altéré tout simplement. et si tu continues sur le système infecté pour vérifier ton objet exécutable, tu n'a aucune certitude que ce que tu lis est la réalité du fichier.

Déjà dans les années 1990, les virus savaient intercepter le système pour se rendre indétectable.

GNU/Linux est robuste, mais root est-il attaqué avec cette faille ou une autre faille encore inconnue du grand publique que nous sommes ?

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

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

ignace72 a écrit :

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 ?

Dans l'absolu, il vaut mieux toujours bloquer les accès distants à tout ce qui n'est pas nécessaire. Si tu as un serveur FTP et un serveur SSH que tu n'utilises qu'en local, c'est très bien que ton routeur bloque les accès distants. C'est plus embêtant si tu as un serveur web en production sur une machine, qui par nature doit être accessible de l'extérieur. C'est ce genre de cas qui est concerné.

En tout cas, on le redit : si vous n'avez pas de machines qui font office de serveur, vous ne craignez absolument rien. Et même si c'est le cas et que vous faites tourner un petit serveur qui n'héberge pas de données à risque, le plus gros problème potentiel que vous aurez c'est qu'un guignol s'amuse à transformer votre serveur en bot pour envoyer du spam ou en site de phishing. Rien de bien nouveau, c'est un risque qui existe de toute façon même sans avoir un shell qui fait n'importe quoi.

Ce qui est plus inquiétant, c'est que cette faille soit exploitée sur les sites bancaires et les gros sites marchands comme Amazon. Là, il y a un vrai risque de vol de données.

L_d_v_c@ a écrit :

Si on peut modifier les fichiers du serveur web qui distribuerait des versions de sources ou des distributions GNU/Linux …

Je doute fortement qu'il y ait un hacker très très méchant qui attendait dans l'ombre la divulgation d'une faille qui lui permettrait enfin, après des années à fomenter son coup, de pouvoir distribuer des sources modifiées de Linux au monde entier. Il pouvait certainement atteindre plus facilement son but en balançant des patches pour le noyau sur la mailing list officielle.

Piquer le mot de passe, on s'en fiche, mais si on trouve le mot de passe root, donc l'accès root, on peut installer chevaux de Troie et compagnie, mais si quelqu'un ou un État installe des VMBR alors il faut tout reprendre car il est impossible de détecter les VMBR … et il est possible de faire des VMBR multiplateformes et multi-OS pour ces gens-là … (il suffit d'écrire des VMBR métamorphiques)

Non mais arrêtez de psychoter et de partir dans des délires paranos. De toute façon, la NSA n'a pas besoin de ce genre de faille pour réussir à se connecter en root sur ton PC et installer ses conneries (*musique inquiétante*). Par contre, l'Ukrainien avachi dans son cybercafé qui cherche à piquer des numéros de cartes bancaires pour les revendre 12 centimes pièce, ça va bien l'aider de pouvoir tripatouiller un shell sur un serveur web.

Dernière modification par abelthorne (Le 28/09/2014, à 11:51)

nesthib · Le 28/09/2014, à 12:07

@L_d_v_c@ : Il ne devrait désormais pas y avoir d'erreur lorsque la commande de test de la faille est lancée.

L_d_v_c@ a écrit :

PS: peux-tu rajouter %NOINDEX% en haut de ton message s'il-te-plaît ?

Ça ne sert strictement à rien, surtout pas à éviter l'indexation par des moteurs de recherche. Ce code est uniquement utilisé dans la discussion des photos par le bot qui les récupère.

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

abelthorne a écrit :

…
Non mais arrêtez de *** et de partir dans des *** ****.
…

Je ne suis pas content que mon savoir soit qualifié des mots que tu as employés.
Relis-moi s'il-te-plaît, et vérifie par toi-même ce qui est faisable de nos jours avant de juger s'il-te-plaît abelthorne, et si tu peux éditer ton message et mettre des guillemets ou d'autres mots, je t'en remercie par avance.

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

Compte supprimé · Le 28/09/2014, à 12:34

nesthib a écrit :

@L_d_v_c@ : Il ne devrait désormais pas y avoir d'erreur lorsque la commande de test de la faille est lancée.
ludovic@ludovic-G41MT-S2PT:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
ludovic@ludovic-G41MT-S2PT:~$ 
Ça ne sert strictement à rien, surtout pas à éviter l'indexation par des moteurs de recherche. Ce code est uniquement utilisé dans la discussion des photos par le bot qui les récupère.

Bon, alors je vais éditer mon message et peux-tu éditer celui de PPdM s'il-te-plaît, je dois vérifier que ce que m'ont raconté ma petite "tribu d'informaticiens SSII de région Bordelaise" n'apportera d'ennuis à personne, je suis parti du fait qu'il n'ont pas outrepassé d'éventuelles confidentialités en me les racontant.
Merci nesthib.

édit : À moins que tu me lise PPdM ?

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

jplemoine · Le 28/09/2014, à 12:40

L_d_v_c@ a écrit :

Bon, alors je vais éditer mon message et peux-tu éditer celui de PPdM s'il-te-plaît, je dois vérifier que ce que m'ont raconté ma petite "tribu d'informaticiens SSII de région Bordelaise" n'apportera d'ennuies à personne, je suis parti du fait qu'il n'ont pas outrepassé d'éventuelles confidentialités en me les racontant.

Pourquoi crois-tu que je suis resté évasif dans ma réponse ? Il y a des choses que l'on peut dire car elles sont plus ou moins publiques et il y a des choses qui sont classées : on ne peut rien dire...
Ce que je t'ai donné sont des choses que tu peux voir sur mon CV (entre autres supports) et sont autorisées.

Compte supprimé · Le 28/09/2014, à 12:43

[HS] La justification de la sériosité de mes questions et mises en garde autour des infections ici [/HS]
Merci de bien vous documenter.
Cordialement,
Ludovic

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

nesthib · Le 28/09/2014, à 12:56

Merci, (encore une fois), d'arrêter le HS, ce fil est dédié à la faille de bash, pas à des discussions généralistes sur la sécurité ou autres.

Par ailleurs, je ne vais certainement pas modifier le message de PPdM sans raison. Tu peux le lui demander toi même. J'en profite pour signaler que si vous perdiez cette inutile habitude de citer l'intégralité des message précédents pour répondre au message précédent (quel est l'intérêt de dupliquer le message alors qu'il est au dessus ?), le problème ne se poserait pas (et ça n'est pas faut de vous avoir prévenu à de multiples reprises ces derniers jours…)

PPdM · Le 28/09/2014, à 12:56

J'ai lu, pas de souci, il faut que tu apprenes a relativiser les choses, tu veux trop être précis, rigoureux, ce qui est une qualité en soit, mais la vie est approximative, changeante, incohérente, bordélique, et il faut faire avec, trente ans que je vis avec une perfectionniste maniaque, donc je crois que je sais de quoi je parle, tu te pourri la vie avec ta recherche du parfait, contente toi de faire ce que tu fais, le mieux possible, la perfection n'est pas de ce monde, ni d'un autre !
Ne prend pas mal ce que je viens d’écrire, j'aime bien les gens comme toi, il en faut, et il faut des gens comme moi, je ne suis pas meilleur, ni toi non plus, c'est nos difference qui font ce que nous sommes, et c'est la somme de toutes nos differences qui font le génie de l'humanité.

Dernière modification par PPdM (Le 28/09/2014, à 13:11)

yann_001 · Le 28/09/2014, à 13:06

@nesthib

Il y a une erreur dans l'annonce. La dernière mise à jour installe sur Precise, le paquet 4.2-2ubuntu2.5 et non le 4.2-2ubuntu2.4.

nesthib · Le 28/09/2014, à 13:17

OK. corrigé. merci.

PPdM · Le 28/09/2014, à 13:19

nesthib a écrit :

Merci, (encore une fois), d'arrêter le HS, ce fil est dédié à la faille de bash, pas à des discussions généralistes sur la sécurité ou autres.
Par ailleurs, je ne vais certainement pas modifier le message de PPdM sans raison. Tu peux le lui demander toi même. J'en profite pour signaler que si vous perdiez cette inutile habitude de citer l'intégralité des message précédents pour répondre au message précédent (quel est l'intérêt de dupliquer le message alors qu'il est au dessus ?), le problème ne se poserait pas (et ça n'est pas faut de vous avoir prévenu à de multiples reprises ces derniers jours…)

modifié
sinonCiter or not citer that is the question!!

maxire · Le 28/09/2014, à 13:51

Question pratiquo pratique:

Il est proposé de remplacer bash par zsh pour pallier au problème actuel de Bash.
Sous Ubuntu le shell par défaut est déjà dash (/usr/bin/sh pointe sur dash).
Concrètement, comment être certain que Apache ou ssh n'utilisent pas bash, faut-il supprimer bash et faire pointer /usr/bin/bash sur zsh?
Sachant que la demande de suppression de bash suscite le message suivant::

Vous êtes sur le point de faire quelque chose de potentiellement dangereux
Pour continuer, tapez la phrase « Oui, faites ce que je vous dis ! »
 ?]

En bref, ce remplacement ne semble pas si facile.
C'est sans doute un bête problème de syntaxe, je viens de jeter un oeil dans un script livré avec ssh j'ai en première ligne ceci:

#!/bin/sh

À priori c'est donc dash qui sera appelé lors de l'exécution de ce script.
Conclusion sans doute trop rapide:
Cette faille de sécurité n'est pas nécessairement un problème pour Ubuntu.

[Edit]
Bon sang mais c'est bien sûr, poser la question c'est y répondre, il suffiit de définir le shell à utiliser via l'option -s de usermod ou useradd et le problème est réglé.

Dernière modification par maxire (Le 28/09/2014, à 14:04)

Compte supprimé · Le 28/09/2014, à 14:49

nesthib a écrit :

…
Pour savoir si votre machine est affectée, lancez la commande :
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Une machine vulnérable retournera :
vulnerable
this is a test
Une machine non affectée retournera :
this is a test

Question sans importance, j'essaie de comprendre la ligne env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Je crois que j'avais mal compris (je ne maîtrise pas bash), est-ce la commande env ou bash -c qui fait des blagues ?
dès que env a trouvé le ';' env a enchaîné echo vulnérable alors qu'il aurait dû chercher l'autre apostrophe ' ?

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

Compte anonymisé · Le 28/09/2014, à 14:56

À abelthorne
Merci de ta réponse.

ssdg · Le 28/09/2014, à 15:04

L_d_v_c@ a écrit :

[...]
Question sans importance, j'essaie de comprendre la ligne env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Je crois que j'avais mal compris (je ne maîtrise pas bash), est-ce la commande env ou bash -c qui fait des blagues ?
dès que env a trouvé le ';' env a enchaîné echo vulnérable alors qu'il aurait dû chercher l'autre apostrophe ' ?

Si j'ai bien compris, env met dans X la chaine de caractères '() { :;}; echo vulnerable' comme tu pourrais mettre 'HOME=/home/ldvc' ou 'LANG=FR'

Et quand bash se lance, il lit l'environnement, y trouve X et y trouve quelque chose qui ressemble à la définition d'une fonction. Il la charge en mémoire en executant 'X(){;;};echo vulnerable' (il remplace le = par rien)
et comme dans la variable il n'y avait pas qu'une définition de fonction, il execute aussi "le reste" à savoir le echo (ou ce qu'on aurait pu y mettre)

Compte supprimé · Le 28/09/2014, à 15:24

réponse à http://forum.edubuntu-fr.org/viewtopic. … #p18145371

Il me semble (je n'affirme donc pas) que Bash se lance car on l'appelle explicitement «bash -c» puisque c'est le but de la commande «env» que celui d'exécuter :

http://www.linux-france.org/article/man-fr/man1/env-1.html a écrit :

SYNOPSIS
env [-] [-i] [-u name] [--ignore-environment]
[--unset=nom] [--help] [--version] [nom=valeur]... [com
mande [args...]]
env
…
Cette page de manuel documente la version GNU de env.
env exécute une commande dans un environnement modifié par
les spécifications fournies sur la ligne de commande
Les arguments du type 'nom=valeur' remplissent la variable
d'environnement nom avec la valeur indiquée.
…

Mais on aurait pu lancer ls à la place de bash

env x='() { :;}; echo vulnerable' ls /
bin    dev   initrd.img      lib64	 mnt   root  selinux  sys  var
boot   etc   initrd.img.old  lost+found  opt   run   srv      tmp  vmlinuz
cdrom  home  lib	     media	 proc  sbin  swap     usr  vmlinuz.old

Le man de env est plus complet, et technique …
Ensuite, je vais laisser faire les autres, je voulais juste essayer de comprendre env.
Merci ssdg
édit … mais je n'en comprends pas grand chose … tant pis … bon dimanche.

édit 2 :

ssdg a écrit :

et comme dans la variable il n'y avait pas qu'une définition de fonction, il execute aussi "le reste" à savoir le echo (ou ce qu'on aurait pu y mettre)

En relisant une trentaine de fois, je commence peut-être à comprendre …
édit 3 : bien non, je ne comprends pas tout …

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

Compte supprimé · Le 28/09/2014, à 20:37

L_d_v_c@ a écrit :

Question sans importance, j'essaie de comprendre la ligne env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Je crois que j'avais mal compris (je ne maîtrise pas bash), est-ce la commande env ou bash -c qui fait des blagues ?

Je dirais que Bash ne contrôlait pas la manière dont il interprétait des variables (pas besoin d'être root!!!). Quand ta machine est à jour et si tu exécutes ladite commande, le retour est : this is a test (ça s'est normal).
Donc bash ne permet plus l'éxécution de code arbitraire comme (cette variable d'environnement par exemple) env x='() { :;}; echo vulnerable' (code non exécuté).

Bref, t'avais presque un full accès aux machines puisque il est le shell par défaut d’un grand nombre de systèmes (Gnu/Linux, BSD, Apple...), c’est-à-dire l’interface par laquelle on peut piloter diverses opérations par des lignes de commande...

Dernière modification par ignus (Le 28/09/2014, à 20:47)

PPdM · Le 28/09/2014, à 20:38

Il serait temps de remettre une baniere plus discrète, celle-ci est un vrai repoussoir,et le danger pas si grand, a part pour les serveurs !!

CM63 · Le 28/09/2014, à 20:44

En plus on ne se rend pas compte quand ça change de date, là je viens de réaliser qu'il y a une update d'aujourd'hui.

Compte supprimé · Le 28/09/2014, à 20:48

À ce jour sur Wheezy, je n'ai eu que deux mises à jour de bash ... Le problème semble résolu pour Debian, enfin, nous verrons

CM63 · Le 28/09/2014, à 20:50

Bonsoir,

ignus a écrit :

Je dirais que Bash ne contrôlait pas la manière dont il interprétait des variables (pas besoin d'être root!!!).

Je ne comprends toujours pas. Moi quand j'essaie de faire quelque chose qui demande les droits root, le système me demande le mot de passe du root, et si je ne tape pas le mot de passe correct cela ne va pas marcher. Et ce n'est pas le fait de définir ma commande dans une variable environnement qui va me permettre d'outre passer cela (enfin bon je vais faire un essai avec un chmod). Je ne comprends toujours pas le principe de la faille.

A plus

Dernière modification par CM63 (Le 28/09/2014, à 20:51)

Compte supprimé · Le 28/09/2014, à 20:58

Bin en gros, tu peux gravement affecter un serveur web ou un service distant. Bash étant un interpréteur de commande des systèmes Unix, ça craint quoi
L'exemple était donné en première page de ce fil par Nesthib...

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Et une machine vulnérable renvoyait:

vulnerable
this is a test

Une machine protégée :

this is a test

Remplace l'instruction echo vulnérable par autre chose de bien méchant et hop, la machine était infectée... Botnet, phishing etc etc...

Dernière modification par ignus (Le 28/09/2014, à 20:59)

CM63 · Le 28/09/2014, à 21:04

Oui, j'ai bien vu l'explication, mais je ne la comprends toujours pas. C 'est le fait que la fonction n'a pas de nom qui fait que Bash ne va pas seulement la définir-prendre en compte mais qu'il va tout de suite l’exécuter?

J'essaie de faire un essai mais je n'arrive pas à trouver une commande simple qui demande les droits root. chmod marche sans être root.

Dernière modification par CM63 (Le 28/09/2014, à 21:06)

Compte supprimé · Le 28/09/2014, à 21:06

Avec la commande env, bash permettait une élévation des privilèges. Donc pas besoin d'être root. La commande env est une commande d'environnement permettant des actions temporaires
C'est plus clair pour toi ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 28/09/2014, à 11:31

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

#202 Le 28/09/2014, à 11:39

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

#203 Le 28/09/2014, à 12:07

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

#204 Le 28/09/2014, à 12:28

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

#205 Le 28/09/2014, à 12:34

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

#206 Le 28/09/2014, à 12:40

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

#207 Le 28/09/2014, à 12:43

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

#208 Le 28/09/2014, à 12:56

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

#209 Le 28/09/2014, à 12:56

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

#210 Le 28/09/2014, à 13:06

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

#211 Le 28/09/2014, à 13:17

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

#212 Le 28/09/2014, à 13:19

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

#213 Le 28/09/2014, à 13:51

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

#214 Le 28/09/2014, à 14:49

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

#215 Le 28/09/2014, à 14:56

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

#216 Le 28/09/2014, à 15:04

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

#217 Le 28/09/2014, à 15:24

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

#218 Le 28/09/2014, à 20:37

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

#219 Le 28/09/2014, à 20:38

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

#220 Le 28/09/2014, à 20:44

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

#221 Le 28/09/2014, à 20:48

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

#222 Le 28/09/2014, à 20:50

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

#223 Le 28/09/2014, à 20:58

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

#224 Le 28/09/2014, à 21:04

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

#225 Le 28/09/2014, à 21:06

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

Pied de page des forums