Hacker une commande

Le Thu, 19 Aug 2010 14:25:28 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :

In article <4c6d339c$0$7867$426a34cc@news.free.fr>,
Éric Lévénez <usenet@levenez.com> wrote:

Le 19/08/10 15:10, Marc Espie a écrit :

Le trou de securite que je connais, c'est une race condition, ou tu peux
faire un lien symbolique sur un script a bit s connu, et changer au bon
moment ce lien par le "vrai" script. Sur un unix classique, si tu lances
foo, ca va se transformer en "/bin/sh foo", donc exploitable.

Effectivement. J'ai tellement vus de systèmes avec des shells avec bits
s (sur SYSV, SunOS, 4.3BSD...) mais aussi avec bit w permettant de
modifier à sa guise ces scripts. Mais même avec le bit r, voir le code
en clair du script permet souvent de trouver comment simplement
l'appeler pour hacker une commande non attendue. Trop facile à tromper
ce bit s.

Security through obscurity...

Sur un unix recent,

C'est quoi un unix récent ? Tu as des exemples ?

OpenBSD

Euh... Le truc qui segfaulte sur un bête pthread_create() (au moins
en 4.7 i386, il paraît que c'est corrigé dans le CVS 4.8 que je susi
en train de compiler), qui n'honore pas tout un tas de choses ? Récent,
peut-être, décent, certainement pas.

Un "unix récent" oblige-t-il les utilisateurs à bien coder leurs scripts
? :-)

Rien de particulier aux scripts, hein.

Je ne crois pas aux systemes "verrouilles", ou tu ne peux rien voir, pas
rajouter de programmes. Ou aux gens qui "securisent" leur systeme en
enlevant le compilateur C. Ca me fait toujours rire.

On est deux ;-)

foo est ouvert, puis verifie cote droits, et ca devient
/bin/sh /dev/fd/0, donc plus de race condition...

apres, le fait que ton interpreteur soit plus ou moins sur, c'est une autre
paire de manches, mais ca evite les problemes avec les langages de script.

Pour moi le seul moyen de mieux sécuriser les scripts avec bit s est de
les interdire. :-)

Mais tout cela n'a plus rien à voir avec ce NG.

Ah ben, on peut revenir dans le sujet.

Tu es en train de dire que les langages de script devraient etre langage
"de seconde classe" pour plein de raisons qui sont toutes demontables.

- les gens peuvent ecrire de la merde avec un langage de script.
Oui, c'est vrai de tous les langages. On trouve des trous de securite
partout. Tout ce que va faire un langage donne, c'est rajouter une ou
deux checkbox pour un manager (c'est pour ca que C a mauvaise presse
"grace" aux buffer overflow par rapport a du java, alors qu'un programme
mal ecrit en java est tout aussi dangereux, voire plus qu'un programme
mal code en C). Comme il y a de bonnes pratiques pour ecrire du C correct,
il y a de bonnes pratiques pour faire du shell "sur" (qui commencent
le plus souvent par un set -x, un PATH explicite, et quelques unset sur
toutes les variables de localisation)

Je ne comprends même pas qu'il n'y ait pas une option portable pour virer
tout l'environnement style /bin/sh -X dans le sha-bang.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 19/08/10 16:25, Marc Espie a écrit :

In article<4c6d339c$0$7867$426a34cc@news.free.fr>,
Éric Lévénez<usenet@levenez.com> wrote:

Effectivement. J'ai tellement vus de systèmes avec des shells avec bits
s (sur SYSV, SunOS, 4.3BSD...) mais aussi avec bit w permettant de
modifier à sa guise ces scripts. Mais même avec le bit r, voir le code
en clair du script permet souvent de trouver comment simplement
l'appeler pour hacker une commande non attendue. Trop facile à tromper
ce bit s.

Security through obscurity...

Pour le bit r oui, pas pour le bit w.

Sur un unix recent,

C'est quoi un unix récent ? Tu as des exemples ?

OpenBSD

Et sur cet "unix récent", tous les programmes de scripts utilisent
/dev/fd et les utilisateurs pensent que cela est vraiment suffisant ? Il
y a d'autres "unix récents" qui font cela ?

Un "unix récent" oblige-t-il les utilisateurs à bien coder leurs scripts
? :-)

Rien de particulier aux scripts, hein.

Oui, mais pour les scripts, c'est pire, bien pire.

Tu es en train de dire que les langages de script devraient etre langage
"de seconde classe" pour plein de raisons qui sont toutes demontables.

Je n'ai jamais dit cela, meêm si... :) Je parlais de bit s et de
l'utilisation des bits r et w. Mais ce problème n'est pas lié au bit s,
j'ai déjà modifié des shells de démarrage d'applis (en 0777) pour avoir
accès à root car la personne utilisant la machine n'était pas disponible
pour me donner le mot de passe root. Les scripts c'est la plaie, c'est
juste une constatation.

C'est tellement hors sujet que l'on devrait arrêter ce fil.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Éric Lévénez écrivit :

Mais tout cela n'a plus rien à voir avec ce NG.

Parce qu'il y eu un instant où ce fut le cas ?

(désolé Éric, mais c'était trop tentant)


Antoine

In article <slrni6qh5t.4ff.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:

Le Thu, 19 Aug 2010 14:25:28 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :

OpenBSD

Euh... Le truc qui segfaulte sur un bête pthread_create() (au moins
en 4.7 i386, il paraît que c'est corrigé dans le CVS 4.8 que je susi
en train de compiler), qui n'honore pas tout un tas de choses ? Récent,
peut-être, décent, certainement pas.

C'est pas parce que tu as une experience malheureuse avec un des coins
les plus crades du systeme que tout est a jeter, bien ehuerusement.

In article <4c6d460f$0$24805$426a34cc@news.free.fr>,
Éric Lévénez <usenet@levenez.com> wrote:

Et sur cet "unix récent", tous les programmes de scripts utilisent
/dev/fd et les utilisateurs pensent que cela est vraiment suffisant ? Il
y a d'autres "unix récents" qui font cela ?

C'est une correction du noyau, le programme de script n'a pas vraiment grand
chose a y voir. C'est le code de execve() qui est en cause, pas celui du
shell...

Un "unix récent" oblige-t-il les utilisateurs à bien coder leurs scripts
? :-)

Rien de particulier aux scripts, hein.

Oui, mais pour les scripts, c'est pire, bien pire.

Je ne suis totalement pas d'accord, et j'ai avance quelques arguments.

Tu es en train de dire que les langages de script devraient etre langage
"de seconde classe" pour plein de raisons qui sont toutes demontables.

Je n'ai jamais dit cela, meêm si... :) Je parlais de bit s et de
l'utilisation des bits r et w. Mais ce problème n'est pas lié au bit s,
j'ai déjà modifié des shells de démarrage d'applis (en 0777) pour avoir
accès à root car la personne utilisant la machine n'était pas disponible
pour me donner le mot de passe root. Les scripts c'est la plaie, c'est
juste une constatation.

Dans le paragraphe qui precede, le souci est le 0777, pas le fait que
ca soit un script... tu aurais pu faire le meme type de manip avec un
programme compile.

Le Thu, 19 Aug 2010 15:22:31 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :

In article <slrni6qh5t.4ff.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:

Le Thu, 19 Aug 2010 14:25:28 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :

OpenBSD

Euh... Le truc qui segfaulte sur un bête pthread_create() (au moins
en 4.7 i386, il paraît que c'est corrigé dans le CVS 4.8 que je susi
en train de compiler), qui n'honore pas tout un tas de choses ? Récent,
peut-être, décent, certainement pas.

C'est pas parce que tu as une experience malheureuse avec un des coins
les plus crades du systeme que tout est a jeter, bien ehuerusement.

Certainement, mais c'est un peu dommage. Je trouve bizarre de dire
que cet OS est particulièrement sécurisé alors que tout ce qui peut
poser problème est désactivé. Lorsque tu joues avec les piles
alternatives, les signaux, les threads, bref, que tu utilises
POSIX.1 sans le pousser dans ses retranchements, ton code ne compile
pas ou ne fonctionne pas. Et utiliser une pile alternative est assez
utile, surtout pour récupérer les erreurs de code récursif en cas de
dépassement de pile.

Je reproche à OpenBSD de définir des variables (dans pthread.h)
alors que _rien_ derrière n'est codé pour les utiliser
(PTHREAD_SCOPE_SYSTEM). Soit on la positionne et on l'utilise, soit
on ne la positionne pas. Mais la positionner pour qu'à l'exécution,
ton code se plante sur une erreur, c'est absurde.

Laisser passer dans une release stable (4.7) un segmentation fault
dans pthread_create() est bizarre.

Bon, je retourne écrire des workarounds pour OpenBSD.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

In article <slrni6qjhi.4ff.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:

Le Thu, 19 Aug 2010 15:22:31 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
alors que _rien_ derrière n'est codé pour les utiliser
(PTHREAD_SCOPE_SYSTEM). Soit on la positionne et on l'utilise, soit
on ne la positionne pas. Mais la positionner pour qu'à l'exécution,
ton code se plante sur une erreur, c'est absurde.

Si tu te proposes pour maintenir pthread, tu es le bienvenu.

L'idee, c'est qu'il y a un grand nombre de limitations tres embetantes
(le fait que les fd soient TOUS non-bloquants, sous le capot, avec pthread,
les utilisations de signaux, la gestion des piles de threads en mode
utilisateur) qui font que personne chez nous ne bosse reellement dessus.
Le plan actuel, c'est vraiment de finir rthreads (une vraie implementation
de threads noyau) et de passer dessus.

Le Thu, 19 Aug 2010 15:41:14 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :

In article <slrni6qjhi.4ff.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:

Le Thu, 19 Aug 2010 15:22:31 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
alors que _rien_ derrière n'est codé pour les utiliser
(PTHREAD_SCOPE_SYSTEM). Soit on la positionne et on l'utilise, soit
on ne la positionne pas. Mais la positionner pour qu'à l'exécution,
ton code se plante sur une erreur, c'est absurde.

Si tu te proposes pour maintenir pthread, tu es le bienvenu.

C'est gentil, mais j'ai assez de Linux/sparc et de NetBSD/sparc pour
m'amuser en ce moment. Ce n'est pas parce que je compte abandonner
Linux/sparc (parce que le noyau suit des voies amha erronées...) que
je vais avoir plus de temps pour OpenBSD. Je préfère rester pour
l'instant à NetBSD.

Je crois que tu n'as pas compris. Que tout ne sois pas disponible
est une chose. Ce qui est franchement désagréable, c'est de
_pouvoir_ utiliser une fonction alors que rien n'est derrière. Si
dans le pthread.h, PTHREAD_SCOPE_SYSTEM n'était pas défini, on se
poserait la question lors de la compilation alors que là, un code peut
tourner sans problème jusqu'au moment où il va appeler la fonction et
lever une exception. Lorsqu'on a de la chance, c'est une erreur récupérable,
mais ça peut aller au segfault, ce qui est gênant.

Idem pour chez choses comme siginfo. On devrait pouvoir se rendre
compte que la structure siginfo_t est vérolée avec l'absence de
SA_SIGINFO. Dans OpenBSD, SA_SIGINFO est défini, mais la structure
n'est pas remplie correctement.

Ces remarques ne sont pas à prendre comme provenant de quelqu'un qui
reproche le boulot fait par une équipe de développeurs parce que je
sais ce qu'est l'écriture d'un logiciel complexe et celui d'un OS.
C'est simplement les remarques de quelqu'un qui doit porter _aussi_
ses logiciels sous OpenBSD et c'est porter un logiciel complexe sous
OpenBSD est une misère par rapport à Net, Free, Solaris ou tous les
autres Unix. C'est d'autant plus une misère que ton code compile
mais ne fonctionne pas !

L'idee, c'est qu'il y a un grand nombre de limitations tres embetantes
(le fait que les fd soient TOUS non-bloquants, sous le capot, avec pthread,
les utilisations de signaux, la gestion des piles de threads en mode
utilisateur) qui font que personne chez nous ne bosse reellement dessus.
Le plan actuel, c'est vraiment de finir rthreads (une vraie implementation
de threads noyau) et de passer dessus.

Et c'est dans quel état actuellement, rthread ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB écrivit :

Certainement, mais c'est un peu dommage. Je trouve bizarre de dire
que cet OS est particulièrement sécurisé alors que tout ce qui peut
poser problème est désactivé.

C'est pourtant une attitude courante en matière de sécurité (pas
informatique, mais au sens large), quand tu y regardes.

Lorsque tu joues avec les piles
alternatives, les signaux, les threads, bref, que tu utilises
POSIX.1 sans le pousser dans ses retranchements, ton code ne compile
pas ou ne fonctionne pas.

Voilà. De la même manière, dans les années 50-60 on a interdit aux
Formule 1 de rouler en ville ; et dans les années 80 on a volontairement
limité les performances des voitures de sport (genre limiteur de vitesse
à 250 km/h).

Quant à l'argument « POSIX.1 sans le pousser dans ses retranchements »,
je n'achètes pas : Posix est un contrat, qui cherchait à créer un
équilibre, balance, justice, toussa ; pousser dans ses retranchements,
c'est chercher la petite bête, autrement dit donner plus de poids à la
forme sur le fond : en définitive, le meilleur moyen de ne pas obtenir
les meilleurs contreparties possibles d'un contrat. ÀMHA.
Je ne veux pas dire que cela doit t'interdire de faire pression sur les
/vendeurs/ pour qu'ils améliorent leurs implémentations dans le sens
indiqué par la norme : au contraire, il faut absolument les pousser.
Mais tu ne peux pas te poser dans la position du chevalier blanc.


Maintenant, dans le détail de tes arguments dans l'affaire « pthreads
contre OpenBSD », peut-être qu'en effet OpenBSD a sorti un produit qui
n'est pas au niveau où il devrait être ; malheureusement, c'est
tellement devenu courant en informatique (cf. la blague Gates-vs-GM) de
sortir des versions avec des morceaux « niveau bêta » que certains (dont
Marc il y a quelques mois, si je me souviens bien) s'en serve pour
justifier en quelque sorte l'existence même de leurs emplois...
ce qui n'est pas forcément stupide d'un point de vue économique (c'est
toute l'idée de la « nouvelle économie » ou de l'économie des nouvelles
technologies, en fait) : au final, c'est le client réel (le tien, en
direct) qui va payer le développement (le tien) au moment où il sera
fait : à toi de savoir lui faire payer le bon prix pour ton boulot.


Antoine

Vu tes talents de scripteur, c'est pas tres etonnant....

#! /bin/sh
echo "$@" >>/tmp/ncutil.log
exec /usr/sbin/ncutil.bin "$@"

a deja plus de chance de fonctionner.

Houla, houlala, tu aurais meme pu etre plus méchant avec moi. Je viens de
relire ce que j'ai écrit et oui, il y a de quoi rire. Je crois que j'ai
mérité la médaille de la boulette shell de l'année :)

Si tu es sur MacOSX, ca a des chances d'etre faisable a coups de dtrace
egalement, sans avoir a rien developper...

En réponse à tout ce long thread, oui je suis bien sur Mac OS X et non, je ne
me soucis pas des problèmes de sécurité. J'ai juste un programme en Obj-C qui
appelle ncutil mais je ne sais pas comment. Je voulais juste voir quels
paramètres étaient passés en argument. Maintenant que c'est chose faite, mon
bout de code est supprimé. Quant à la sécurité des appels Obj-C en mode
privilégié, ça dépasse largement mon problème :)

En tout cas, merci pour tes ces réponses !