Et effectivement, en lisant le man de bash, on comprend que:
«
. fichier [arguments]
Lire et exécuter les commandes contenues dans le fichier avec
l'environnement du shell en cours
»
Donc, bash peut donc exécuter des fichiers (ou plus exactement les
commandes contenues dans ce fichier) non exécutables.
Est-ce un trou de sécu ?
Si oui, comment empêcher ce comportement ?
[ GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu) ]
Merci
--
Hugo NPN (i --> ee)
Passe que moi, au départ, j'avais fait informatique comme études, pas NT,
et je voudrais revenir à mon métier premier.
-+- BB in Guide du Linuxien pervers - Bien configurer son métier. -+-
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
l'indien
On Sun, 20 Feb 2005 03:35:57 +0100, Hugolino wrote:
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$ qu'on pouvait faire un truc du genre:
03:22:06 ~ $ echo "echo youpi" > plop 03:22:44 ~ $ ls -l plop 4 -rw-r--r-- 1 hugo hugo 11 2005-02-20 03:22 plop 03:22:50 ~ $ . plop youpi
Et effectivement, en lisant le man de bash, on comprend que:
« . fichier [arguments] Lire et exécuter les commandes contenues dans le fichier avec l'environnement du shell en cours »
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Il ne l'execute pas: il interprete les commandes dans le shell courant, c'est assez différent: il ne crée pas de nouveau process, il ne fait que lire et interpréter le fichier dans le process courant. C'est quand on appelle 'execve' que le noyau vérifie que le fichier est executable. Si on lance n'importe quel interpréteur en lui spécifiant un fichier de commande, celui ci l'interpretera, en vérifiant juste qu'il peut lire le fichier en question. La commande 'source' du shell est un cas particulier de ce comportement.
Est-ce un trou de sécu ?
Non.
Si oui, comment empêcher ce comportement ?
En modifiant les sources de bash et interdisant la commande 'source' ?
On Sun, 20 Feb 2005 03:35:57 +0100, Hugolino wrote:
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$626a14ce@news.free.fr>
qu'on pouvait faire un truc du genre:
Et effectivement, en lisant le man de bash, on comprend que:
«
. fichier [arguments]
Lire et exécuter les commandes contenues dans le fichier avec
l'environnement du shell en cours
»
Donc, bash peut donc exécuter des fichiers (ou plus exactement les
commandes contenues dans ce fichier) non exécutables.
Il ne l'execute pas: il interprete les commandes dans le shell courant,
c'est assez différent: il ne crée pas de nouveau process, il ne fait
que lire et interpréter le fichier dans le process courant.
C'est quand on appelle 'execve' que le noyau vérifie que le fichier est
executable. Si on lance n'importe quel interpréteur en lui spécifiant un
fichier de commande, celui ci l'interpretera, en vérifiant juste qu'il
peut lire le fichier en question.
La commande 'source' du shell est un cas particulier de ce comportement.
Est-ce un trou de sécu ?
Non.
Si oui, comment empêcher ce comportement ?
En modifiant les sources de bash et interdisant la commande 'source' ?
On Sun, 20 Feb 2005 03:35:57 +0100, Hugolino wrote:
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$ qu'on pouvait faire un truc du genre:
03:22:06 ~ $ echo "echo youpi" > plop 03:22:44 ~ $ ls -l plop 4 -rw-r--r-- 1 hugo hugo 11 2005-02-20 03:22 plop 03:22:50 ~ $ . plop youpi
Et effectivement, en lisant le man de bash, on comprend que:
« . fichier [arguments] Lire et exécuter les commandes contenues dans le fichier avec l'environnement du shell en cours »
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Il ne l'execute pas: il interprete les commandes dans le shell courant, c'est assez différent: il ne crée pas de nouveau process, il ne fait que lire et interpréter le fichier dans le process courant. C'est quand on appelle 'execve' que le noyau vérifie que le fichier est executable. Si on lance n'importe quel interpréteur en lui spécifiant un fichier de commande, celui ci l'interpretera, en vérifiant juste qu'il peut lire le fichier en question. La commande 'source' du shell est un cas particulier de ce comportement.
Est-ce un trou de sécu ?
Non.
Si oui, comment empêcher ce comportement ?
En modifiant les sources de bash et interdisant la commande 'source' ?
JKB
Le 20-02-2005, à propos de Executer un fichier non executable, Hugolino écrivait dans fr.comp.os.linux.configuration :
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$ qu'on pouvait faire un truc du genre:
03:22:06 ~ $ echo "echo youpi" > plop 03:22:44 ~ $ ls -l plop 4 -rw-r--r-- 1 hugo hugo 11 2005-02-20 03:22 plop 03:22:50 ~ $ . plop youpi
Et effectivement, en lisant le man de bash, on comprend que:
« . fichier [arguments] Lire et exécuter les commandes contenues dans le fichier avec l'environnement du shell en cours »
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Est-ce un trou de sécu ?
Si oui, comment empêcher ce comportement ?
Moi, je ne l'empêcherais pas, mais c'est vous qui voyez... Le . est équivalent à la commande source qui est faite pour lire des variables (entre autres). Maintenant, source n'exécute pas directement le script, il lit le script et l'envoie au shell père. C'est pour cela que les droits en lecture seule suffisent.
JKB
Le 20-02-2005, à propos de
Executer un fichier non executable,
Hugolino écrivait dans fr.comp.os.linux.configuration :
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$626a14ce@news.free.fr>
qu'on pouvait faire un truc du genre:
Et effectivement, en lisant le man de bash, on comprend que:
«
. fichier [arguments]
Lire et exécuter les commandes contenues dans le fichier avec
l'environnement du shell en cours
»
Donc, bash peut donc exécuter des fichiers (ou plus exactement les
commandes contenues dans ce fichier) non exécutables.
Est-ce un trou de sécu ?
Si oui, comment empêcher ce comportement ?
Moi, je ne l'empêcherais pas, mais c'est vous qui voyez... Le . est
équivalent à la commande source qui est faite pour lire des
variables (entre autres). Maintenant, source n'exécute pas
directement le script, il lit le script et l'envoie au shell père.
C'est pour cela que les droits en lecture seule suffisent.
Le 20-02-2005, à propos de Executer un fichier non executable, Hugolino écrivait dans fr.comp.os.linux.configuration :
Bonsoir
Je viens de lire un truc qui ma troué le cul sur fcold.
Le Miod a écrit (M-ID : <420e56e1$0$516$ qu'on pouvait faire un truc du genre:
03:22:06 ~ $ echo "echo youpi" > plop 03:22:44 ~ $ ls -l plop 4 -rw-r--r-- 1 hugo hugo 11 2005-02-20 03:22 plop 03:22:50 ~ $ . plop youpi
Et effectivement, en lisant le man de bash, on comprend que:
« . fichier [arguments] Lire et exécuter les commandes contenues dans le fichier avec l'environnement du shell en cours »
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Est-ce un trou de sécu ?
Si oui, comment empêcher ce comportement ?
Moi, je ne l'empêcherais pas, mais c'est vous qui voyez... Le . est équivalent à la commande source qui est faite pour lire des variables (entre autres). Maintenant, source n'exécute pas directement le script, il lit le script et l'envoie au shell père. C'est pour cela que les droits en lecture seule suffisent.
JKB
Matthieu Moy
Hugolino writes:
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Pas que bash.
cp /bin/ls . ls -l total 84
-rwxr-xr-x 1 moy moy 75948 Feb 20 13:07 ls*
chmod -x ls ls -l total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
./ls ./ls: Permission denied.
/lib/ld-linux.so.2 ./ls ls
/lib/ld-linux.so.2 ./ls -l total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
Est-ce un trou de sécu ?
Pour ceux qui pensent que le flag executable a quelque chose a voir avec la sécurité, oui.
En pratique, le fait qu'un fichier ne soit pas executable t'évite de l'executer par erreur, mais ne peut pas empécher quelqu'un qui a vraiment envie de l'executer.
(En fait, du moment que tu as accès en lecture, tu peux faire
cp foo /tmp chmod +x /tmp/foo ...
-- Matthieu
Hugolino <hugolino@fri.fr> writes:
Donc, bash peut donc exécuter des fichiers (ou plus exactement les
commandes contenues dans ce fichier) non exécutables.
Pas que bash.
cp /bin/ls .
ls -l
total 84
-rwxr-xr-x 1 moy moy 75948 Feb 20 13:07 ls*
chmod -x ls
ls -l
total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
./ls
./ls: Permission denied.
/lib/ld-linux.so.2 ./ls
ls
/lib/ld-linux.so.2 ./ls -l
total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
Est-ce un trou de sécu ?
Pour ceux qui pensent que le flag executable a quelque chose a voir
avec la sécurité, oui.
En pratique, le fait qu'un fichier ne soit pas executable t'évite de
l'executer par erreur, mais ne peut pas empécher quelqu'un qui a
vraiment envie de l'executer.
(En fait, du moment que tu as accès en lecture, tu peux faire
Donc, bash peut donc exécuter des fichiers (ou plus exactement les commandes contenues dans ce fichier) non exécutables.
Pas que bash.
cp /bin/ls . ls -l total 84
-rwxr-xr-x 1 moy moy 75948 Feb 20 13:07 ls*
chmod -x ls ls -l total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
./ls ./ls: Permission denied.
/lib/ld-linux.so.2 ./ls ls
/lib/ld-linux.so.2 ./ls -l total 84
-rw-r--r-- 1 moy moy 75948 Feb 20 13:07 ls
Est-ce un trou de sécu ?
Pour ceux qui pensent que le flag executable a quelque chose a voir avec la sécurité, oui.
En pratique, le fait qu'un fichier ne soit pas executable t'évite de l'executer par erreur, mais ne peut pas empécher quelqu'un qui a vraiment envie de l'executer.
(En fait, du moment que tu as accès en lecture, tu peux faire
cp foo /tmp chmod +x /tmp/foo ...
-- Matthieu
TiChou
Dans le message <news:, *Hugolino* tapota sur f.c.o.l.configuration :
Bonsoir
Salut Hugo,
[. fichier]
Si oui, comment empêcher ce comportement ?
Souhaites-tu vraiment supprimer cette fonctionnalité des shells ? Si oui, pourquoi ? En quoi te pose-t-elle problème ?
Si tu es sur une Debian :
$ grep -r '. /' /etc/init.d
Merci
Pas de quoi.
-- TiChou
Dans le message <news:slrnd1ftsd.94e.hugolino@Deborah.RocknRoll.org>,
*Hugolino* tapota sur f.c.o.l.configuration :
Bonsoir
Salut Hugo,
[. fichier]
Si oui, comment empêcher ce comportement ?
Souhaites-tu vraiment supprimer cette fonctionnalité des shells ?
Si oui, pourquoi ? En quoi te pose-t-elle problème ?
