Faille dans bash (connue sous le nom shellshock)

Phénix · 27/09/2014 21:51:21

Bonsoir.

J'ai un peu hésité avant de poster cette information, dans la mesure où ça a très peu de lien avec le thème du forum(quoique ..., voir la suite), mais si cette information peut aider, plus elle sera répandue, mieux elle pourra aider.

En milieu de semaine (mercredi, je crois) une faille concernant "bash", le shell le plus répandu sous Linux, découverte par Stéphane Chazelas, a été dévoilée (juste avant que le premier correctif soit publié), et nommée "shellshock".

Cette faille peut permettre au minimum de prendre un peu plus de contrôle que prévu sur un système, ou du moins de l'utiliser hors des conditions initialement prévues.

Le principe de la faille réside dans l'utilisation/interprétation de l'environnement.
En temps normal, on devrait pouvoir passer un environnement au shell de la façon suivante :
env <variable>=<valeur>

Mais, on peut très bien affecter une fonction à une variable :
env <variable>=() {<ma_fonction>;}

Le problème réside dans le fait que, apparemment depuis l'origine de "bash", aucune contrôle n'est fait sur le contenu de la variable (tout est accepté comme contenu de la variable).

Ce qui fait que la syntaxe suivante est acceptée :
env <variable>='() { echo commande pour faire bien ;}; echo vulnerable /bin/bash -c echo "fin du test"
env <variable>='() { echo commande pour faire bien ;}; echo vulnerable' /bin/bash -c "echo fin du test"
Si votre Linux (Unix) est vulnérable, ça devrait afficher :
commande pour faire bien
vulnerable
fin du test
Sur un système non vulnérable, plusieurs réponses possibles, mais la chaîne "vulnerable" ne doit pas s'afficher.

Dans des conditions idéales, ça ne devrait rien afficher, juste prendre en compte la déclaration de fonction dans la variable "<variable>".

Cette faille n'est utilisable que dans les circonstances suivantes :
- En local par tout accès au shell "bash".
Les conséquences sont nulles, c'est exécuté avec les droits de l'utilisateur qui a lancé le shell.
- A distance en SSH
Conséquences similaires à une exécution de shell en local, ça n'est exécuté qu'avec les droits de l'utilisateur qui se connecte en SSH.
- A semi-distance, par un serveur DHCP.
Il arrive qu'un serveur DHCP soit associé à des scripts écrits en shell (bash, par exemple).
- A distance par un serveur Web.
N'est utilisable que si le serveur Web est à même de lancer des shells dans le répertoire des CGI.
Malheureusement, c'est notamment le cas de CPanel (une console "classique" de l'hébergement Web mutualisé).
- A distance, pour tout serveur qui fait exécuter des scripts écrits en shell directement par le "client".

Dans les trois derniers cas, le serveur est exécuté avec des droits différents de ceux de l'utilisateur connecté, et ça peut donc mener à la possibilité d'accéder à des informations qui ne devraient pas être visibles de l'utilisateur distant.

Sans prendre le pire des cas (un serveur Web lancé avec les droits "root", ce qui est maintenant bien connu comme une erreur fondamentale) et exécutant des scripts écrits en shell (généralement situés dans "cgi-bin" à la racine du serveur Web).
- Le "client" se connecte en positionnant une chaîne compromettante dans les ""headers HTTP (le Referer, par exemple, mais ça peut être les Cookies, ou tout autre en-tête, car la norme CGI impose de mettre dans l'environnement toute valeur positionnée par les "headers").
- Le shell va être appelé avec, comme environnement à prendre en compte, le contenu des "headers".
- Le shell va s'exécuter, et va, avant tout, positionner l'environnement soumis par les "headers".
Si la commande "echo vulnerable" vue plus haut est "rm -rf .", l'arborescence complète du serveur Web est susceptible d'être détruite.
Pire, un accès à une base de données associée, à des fichiers confidentiels, est possible.
Et bien d'autres possibilités, qui ne viennent pas forcément à l'esprit immédiatement ...

La bonne nouvelle (il en faut une quand même ), c'est que jeudi et vendredi, Chet Ramey, la personne en charge du support de "bash", ainsi que les acteurs majeurs du milieu Linux, se sont empressés de proposer un ou plusieurs palliatifs (vérifié pour Redhat/CentOS et Debian).

Apple utilise également "bash" sur les Mac, et probablement ailleurs, mais n'avait pas, ce vendredi 26, proposé de correctif.

Android pourrait être concerné, mais aucune information officielle n'a été publiée.

Que reste-t-il à faire ?

- Si vous êtes client et ne proposez aucune service sur la réseau, pas grand-chose, si ce n'est mettre à jour vos Linux pour être certain d'être à l'abri.
- Si vous proposez des services sur une machine sous Linux, la mettre à jour (pas la peine d'attendre qu'il y ait un problème ...).

Un petit lien quand même avec vos LiveBox favorites :
Sur les LiveBox, comme sur beaucoup de systèmes embarqués, le shell utilisé est "busybox", pas "bash", donc pas de risque de compromission par cette faille.

Dernière modification par Phénix (01/10/2014 17:44:44)

Gisapeca · 01/10/2014 16:18:46

Bonjour,

Sur Mac la syntaxe du test de vulnérabilité du post précédent ne fonctionne pas.
Une syntaxe correcte pour Mac:

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

Si le test retourne "vulnerable", c'est que vous l'êtes, sinon il retourne "test".

Apple propose un correctif selon MacG.co

Des failles en pagaille dans Linux selon cet article de 01.net...

Dernière modification par Gisapeca (01/10/2014 16:22:48)

Phénix · 01/10/2014 17:49:39

Bonsoir.

Il me semblait que l'appel BASH_FUNC... était lié à la correction, non ?

J'ai corrigé ma ligne de commande, elle était un peu erronée (tout se joue dans le placement des simple et double-quotes ...).

Ceci dit, il y a eu beaucoup de buzz sur cette faille, mais en dehors des serveurs exécutant des shells-scripts, la portée est limité puisque le droit d'exécution de la fonction est celui de l'utilisateur qui exécute le shell (SSH et terminal local).
Avec un serveur (Web, PHP faisant des appels système, CUPS, DHCP, ...), c'est différent.

Je ne suis pas surpris que, du coup, on cherche plus de poux au shell et à Linux

Orange Sans Guigne

Annonce

#1 27/09/2014 21:51:21

Faille dans bash (connue sous le nom shellshock)

#2 01/10/2014 16:18:46

Re : Faille dans bash (connue sous le nom shellshock)

#3 01/10/2014 17:49:39

Re : Faille dans bash (connue sous le nom shellshock)

Pied de page des forums