J'avoue que j'ai suivi ça de loin, et j'ai tj pas compris comment c'était exploitable en remote sur un serveur qui ne fait pas tourner de CGI, ni comment on peut élever des privilèges avec. Dans le doute, j'ai patché . et ton dernier message m'a montré l'un de mes serveur non patché alors que je pensait que c'était fait, donc merci bcp !
C'est exploitable quand un shell bash est lancé :
- explicitement : /bin/bash
- implicitement :
/bin/sh pointant sur bash (mais pas sur Debian, puisque sh = dash)
ce que peut se produire :
- explicitement exec ("/bin/bash", blah)
-
exec ("un-script") qui est un script
#!/bin/bash- implicitement notamment avec les commandes comme
system et
popen (par opposition à
exec)
dans un contexte où
le contenu d'une variable d'environnement est fourni par un tiers qui n'est pas autorisé à exécuter des commandes dans le contexte d'exécution du /bin/bash en question, par exemple :
via le réseau :
- client HTTP (
User-agent fabriqué) lançant un programme en CGI sur le serveur (variables "HTTP_machinchose") => accès en tant qu'utilisateur "www" ou "apache"
- serveur DHCP (options DHCP) transmises à un script par le client =>
accès en tant qu'utilisateur root- client SSH ayant la possibilité de login SSH mais
pas d'exécution d'un shell (utilisateur restreint)
- envoi d'email (
qmail avec une adresse destination fabriquée : accès avec les droits du "facteur")
en local :
potentiellement tout programme qui s'exécute avec des droits que tu ne peux pas obtenir régulièrement :
- tout programme Set-quelque chose (SUID, SGID, Set-capability)
- tout programme périodique (comme crontab)
- tout programme de gestion hotplug démarré quand tu branches un périphérique USB ou autre
(ce sont les programmes que tu ne peux pas installer une version perso en remplacement de la version du système)
qui
lancerait un script bash de la façon décrite.
Je n'ai pas étudié la question; les programmes s'exécutant automatiquement peuvent être ou ne pas être vulnérables. Il est évident qu'étudier la question est un très gros boulot et qu'il faudrait étudier chaque variante de script dans chaque distrib.
Donc :
- sur serveur HTTP, les systèmes de "scripts" qui sont plus efficaces que CGI ne sont pas concernés : pour être plus efficaces ils ne lancent pas un "script CGI" à chaque requête HTTP donc les variables d'environnement
ne peuvent pas être utilisé pour transmettre des informations venant de la requête HTTP;
- le client SSH qui a le droit de lancer un shell sur un serveur n'est
pas concerné parce que tout le qu'il peut faire c'est exploiter bash pour exécuter le programme qu'il peut lancer normalement; tu ne peux pas élever tes privilèges avec l'exploit dans ce cas là : au moment où bash est lancé, les droits sont ceux de ton utilisateur SSH.
Pour étudier la question, je suggère d'instrumenter /bin/bash pour qu'il logue toute les utilisations qui ne sont pas un shell interactif.
Logiciels