Le vendredi 26 septembre, p.karatchentzeff@??? a écrit :
> Non *si* le script est setuid, on peut détourner l'appel au shell
> entre le moment où on l'appelle et le moment où le noyau envoie
> réellement la requête au shell.
Tu veux dire : entre le moment où le noyau lance le shell et le moment
où celui-ci lit le script.
> Lire la partie setuid dans la doc de Perl...
Je lis :
In recent years, vendors have begun to supply systems free of
this inherent security bug.
Je croyais que Linux faisait partie des systèmes en question. Je ne sais
plus où j'ai lu ça, je peux me tromper.
Mais là tu parles du problème général des script suid, je ne vois pas le
rapport avec le problème qui nous occupe et qui n'est pas suid.
> system "echo $arg"; # Insecure
> system "/bin/echo", $arg; # Allowed but considered insecure
> # (Perl doesn't know about /bin/echo)
> exec "sh", '-c', $arg; # Considered secure, alas!
>
> dans le premier cas, l'exécution aveugle de $arg peut-être
> catastrophique
pour deux raisons :
- echo peut être n'importe quoi, pas forcément /bin/echo, ça dépend du
PATH ;
- $arg peut contenir des métacaractères du shell : "adieu!; rm -rf /".
Si tu écris
system "/bin/echo $arg";
tu élimines le premier problème (tu appelles bien /bin/echo) mais pas le
deuxième.
> et dans le second cas, le /bin/echo peut être n'importe quoi.
Non ! Le chemin est complètement qualifié, donc c'est bien /bin/echo.
Par ailleurs, tu élimines aussi le deuxième problème du fait qu'avec
cette syntaxe Perl n'appelle pas le shell :
$arg = "adieu!; rm -rf /";
system "/bin/echo", $arg; # affiche "adieu!; rm -rf /"
system "/bin/echo $arg"; # catastrophe
La deuxième commande ne présente pas de danger (je l'ai essayée). Elle
est autorisée par Perl 5.6.1 qui la qualifie dans la doc de « # Secure
(doesn't use sh) ». Elle est interdite par Perl 5.8.0 mais seulement
parce que Perl ne sait pas que /bin/echo ne fait rien de dangereux avec
son PATH : « Perl doesn't know about /bin/echo [...] Perl can't
guarantee that the executable in question isn't itself going to turn
around and execute some other program that is dependent on your PATH ».
Je ne pense pas que PHP connaisse cette subtile différence que fait Perl
entre
system "/bin/echo", $arg;
et
system "/bin/echo $arg";
donc à priori il faut toujours se méfier des métacaractères du shell
dans $arg (`;' dans notre exemple).
Pour revenir au problème de départ :
system("/bin/sh /home/jabber/cmd.sh $argumentsh");
et
system("/home/jabber/cmd.sh $argumentsh");
sont pour moi équivalents au niveau (in)sécurité :
- /bin/sh est toujours /bin/sh (car le chemin est complètement
qualifié), donc pas de problème à ce niveau ;
- /home/jabber/cmd.sh est toujours /home/jabber/cmd.sh -> pas de pb ;
- si $argumentsh contient des métacaractères shell, problème dans les
deux cas ;
- si $PATH est non sûr _et_ utilisé de façon non sûre par
/home/jabber/cmd.sh, problème dans les deux cas.
Donc je ne vois toujours pas l'intérêt d'expliciter /bin/sh, sauf bien
sûr si /home/jabber/cmd.sh n'est pas exécutable.
Edgar.
--
Edgar Bonet Maison : 04 76 21 29 16 Bureau : 04 76 88 10 96
3 rue Jean Prévost Mobile : 06 77 19 79 39 Fax : 04 76 88 11 91
38000 Grenoble guilde@??? www.edgar-bonet.org
