Just Another GNU/Linux Admin’s Blog  -  [Securité] Tester et patcher la faille Shellshock (CVE-2014-6271)

 -  Septembre 2014 - 

Introduction

Vous avez probablement entendu parlé de la faille découverte par Stephane Chazelas, et annoncée hier, le 24/09/2014

La faille permet d’exécuter des codes BASH arbitraires contenus dans les noms de variables d’environnement

La faille concerne toutes es distributions UNIX sur les quelles le shell GNU BASH à été installé, c’est à dire OS X, et la plupart des distro GNU/Linux ou */Linux (certaines versions Android… ) ainsi que les versions de BSD sur les quelles à été installé GNU BASH en tant que dépendance ET utilise en tant que Shell par défaut pour des services accessibles depuis le Net (serveurs web avec support de scripts CGI par exemple)

La situation est plutôt moche… mais la solution existe déjà, du moins pour la plupart des distributions GNU/Linux et UNIX, mais évidemment j’ai pas tous les OS pour tester, donc je m’avance que pour Debian (et on m’a dit qu’Ubuntu à aussi déployé des patchs)

Et alors ? on s’en fout non ? personne n’utilise la ligne de commande en 2014…

Non, pas vraiment, on s’en fou pas…
Vous l’aurez compris le titre de ce paragraphe est sarcastique

Dans la plupart des configuration, notamment quand BASH est le shell par défaut, cette faille est aussi exploitable par le réseau
Parmi les vecteurs d’attaques par réseau, on peut notamment citer les requêtes HTTP, pouvant contenir du code malveillant qui sera exécuté via Common Gateway Interface

On peut dépanner les distributions *NIX qui n’auraient pas encore de patch en limitant la casse avec une bidouille au niveau du pare-feu avec une règle de filtrage pour les requêtes destinées à l’exploitation de cette faille
Avec iptables, on rejette les paquets en fonction du contenu, ici une chaine de caractère spécifique, contenant () {

# iptables-save > iptables_backup
# iptables -I FORWARD 1 -m string --algo bm --hex-string '|28 29 20 7B| ' -j DROP

Mais c’est très limité comme protection, ça filtre les caractères () { donc ça vous protégera contre les attaques automatisées et aveugles, contentant ces caractères en un seul paquet de données réseau, ces caractères permettent d’exécuter le code shell qui va suivre (définition d’une fonction)

Mais si le pirate n’est pas trop con et qu’il se dit que vous avez probablement un pare-feu configuré en conséquence, il pensera probablement à envoyé sa requête divisée en plusieurs paquets, avec chacun contenant un ou deux caractères, ce qui permettra de ne pas reconnaître la signature de l’attaque et de laisser passer les paquet

Le fichier iptables_backup est un fichier de sauvegarde des anciennes règles iptables (sans celle qu’on vient d’ajouter), qu’on peut restaurer en cas de problèmes, mais il devrait pas y en avoir

Dans tous les cas, attaque par réseau ou pas, vous pouvez vous retrouver avec des noms de variables d’environnements contenant du code malveillant, à votre insu

Pour peu que vous exécuter un script ou lancer un programme qui utilise le shell, et que vous avez des variables d’environnement ont été trafiqués pour x raisons, par x moyens, à cause de x facteurs de risques (voire une négligence) vous allez passer une sale journée…

Le code malveillant qui sera exécuté au moment ou le shell BASH est lancé, car c’est à ce moment que le shell lis le contenu des variables d’environnement.

Pleins de programmes exécutent des shell en tâche de fond et laissent les utilisateurs définir des variables d’environnement
Bref, ici le but n’est pas de faire le tour exhaustifs des sources risques et des conséquences, ce serai trop lent

Et la solution réelle… ?

Doucement, j’y arrive, pas de panique, plusieurs distributions ont déjà déployé des patchs
La solution consiste donc à mettre à jour vos machines, les plus curieux d’entrevous voudraient probablement comprendre la faille mieux, voir la tester avant et après l’installation du patch

Pour faire savoir si vous êtes concernés par les faille: voici un test simple et rapide (vous devez être root pour le test)

root@machine:/home/username# env x='() { :;}; echo vuln' bash -c "echo test"

Si vous êtes vulnérable, vous aurez droit à l’affichage de ce qui suit

vuln
test

Car la commande echo vuln contenu dans la variable d’environnement “x” est exécuté

Si vous n’êtes PAS vulnérable, ce qui le cas sous Debian/Ubuntu après un bon apt-get update && apt-get install upgrade
Vous aurez plutôt quelque chose du genre (selon les packages de langues de votre distro)

Le bash -c “echo test” s’exécute normalement car il fait pas partie de l’exploit, c’est un code légitime, alors que le code contenu de la variable “x” bien qu’il ne soit pas malveillant en soit, constitue l’exploit (exécuter un code arbitraire) car il est contenu dans le nom de la variable d’environnement
Ce code est ignoré donc la définition de la fonction est ignorée, l’import de la définition de fonction pour “x” échoue
Conclusion : la patch de votre distribution à été installé si vous avez une sortie similaire

La faille n’est exploitable que s’il y a du code derrière la variable d’environnement, d’où le bash -c “echo test”

PS : Concernant les machines OS X, qui utilise aussi BASH par défaut, a faille existe, mais pour les patchs j’ai pas d’informations, et n’ayant pas aussi je peux pas tester, d’ailleurs je sais même pas si la commande env est la même que sur GNU/Linux, ou c’est la syntaxe change

par /dev/null