Re: Linux et Unix affectés par une faille critique dans Bash
On 2014-09-26 11:10:53 +0200, Francois Lafont wrote:
> Perso, même si c'est vraiment une grosse faille, ça me semble moins
> grave que Heartbleed.
Je suis d'accord.
> Je vais peut-être dire des bêtises (auquel cas
> je serais ravi d'avoir des explications) mais il me semble que si
> l'on prend l'exemple d'un serveur Web, ça n'est pas simple de pouvoir
> exploiter cette faible à distance. Parce qu'il faut déjà que le serveur
> web soit amené à lancer un bash ce qui me semble pas toujours le cas
> (mais il paraît que ça peut arriver avec du cgi par exemple) mais
> surtout il faut que l'attaquant arrive à distance à faire en sorte
> qu'une nouvelle variable d'environnement soit définie au moment où
> le bash s'exécute sur le serveur et ça, ça me semble pas évident à
> distance.
Il suffit d'un script CGI qui stocke par exemple les valeurs des
paramètres dans une variable d'environnement donnée, et qu'un shell
bash soit exécuté par le script CGI ou un descendant. Mais sachant
que l'environnement est hérité par tous les descendants, utiliser
des variables d'environnement pour des paramètres locaux à un
script CGI est une façon sale de programmer.
> En effet, la faille s'exploite en définissant une variable
> d'environnement qui fera partie du processus du bash. Mais si un
> attaquant arrive à faire cela, alors sans même que cette faille existe,
> ça veut dire qu'il peut modifier le PATH par exemple et potentiellement
> déjà mettre un peu la pagaille, non ?
Normalement non, car le processus qui va définir la variable
d'environnement va typiquement choisir un nom fixé, par exemple
PROCNAME_PARAMETERS.
À noter que les variables d'environnement contenant des lettres
minuscules n'ont pas de signification particulière et sont réservées
aux applications. Cela signifie que les utiliser avec n'importe
quelle valeur ne devrait pas poser de problème. Mais bash est
toujours vulnérable sur ce point, car on peut redéfinir ainsi des
commandes standard (echo, eval, exec, set, etc.), dont au moins
une se trouve très probablement dans le script shell. C'est cependant
encore moins évident à exploiter (l'ensemble des applications
affectées se réduit encore).
Il y avait aussi l'exemple d'un serveur DHCP malicieux qui était
donné, mais dans un tel cas, il y a probablement d'autres problèmes
de sécurité (cf les sites qui distribuent des programmes en http
non sécurisé[*], sans même parler de https avec des certificats
dont la révocation n'est pas vérifiée...).
[*] Dans ce cas, l'utilisateur doit pouvoir vérifier la signature (si
celle-ci est fournie) de manière fiable, ce qui n'est pas évident.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: