Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C Hacker une commande

Hacker une commande

20 réponses
Avatar
Zobinette
Bonjour,

Je suis en plein débogage sur OS X et j'ai besoin de connaitre les paramètres
passés à un programme : /usr/sbin/ncutil

J'ai d'abord pensé à faire un petit script shell nommé /usr/sbin/ncutil qui
log les paramètres et appelle le vrai prog juste après (renommé
/usr/sbin/ncutil.bin).

###
echo "$1" >> /tmp/ncutil.log
/usr/sbin/ncutil.bin $1
###

Malheureusement, ça ne marche pas, ncutil étant appelé par du code objective
C en mode privilégié (j'ai une erreur "Invalid argument").

J'ai donc eu l'idée de remplacer mon script shell par un petit prog en C qui
ferait la meme chose, c'est à dire qui me loguerait argv et qui ferait un
system call du vrai ncutil avec les bons paramètres. Sauf que là je sèche un
peu (le C n'est pas trop mon domaine).

Si quelqu'un pourrait m'aider, ça serait super. Notez que OS X accepte très
bien du posix de base et que je compile avec gcc.
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Zobinette
Ah ben c'est bon, j'ai fini par y arriver :)

#include <stdio.h>

int main(int argc, char **argv)
{
int i;
FILE * pFile;
pFile = fopen ("/tmp/ncutil.log","a");

for (i = 0; i < argc; i++)
{
fprintf (pFile, "%s ", argv[i]);
}
fprintf (pFile, "n");
fclose (pFile);

char paf[21] = "/usr/sbin/ncutil.bin";
paf[20] = '';
argv[0] = paf;

return execv(paf, argv);
}
Avatar
espie
In article ,
Zobinette wrote:
Bonjour,

Je suis en plein débogage sur OS X et j'ai besoin de connaitre les paramètres
passés à un programme : /usr/sbin/ncutil

J'ai d'abord pensé à faire un petit script shell nommé /usr/sbin/ncutil qui
log les paramètres et appelle le vrai prog juste après (renommé
/usr/sbin/ncutil.bin).

###
echo "$1" >> /tmp/ncutil.log
/usr/sbin/ncutil.bin $1
###

Malheureusement, ça ne marche pas, ncutil étant appelé par du code objective
C en mode privilégié (j'ai une erreur "Invalid argument").



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.

Si tu es sur MacOSX, ca a des chances d'etre faisable a coups de dtrace
egalement, sans avoir a rien developper...
Avatar
Éric Lévénez
Le 19/08/10 12:45, Marc Espie a écrit :

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.

Si tu es sur MacOSX,



Il est sur iOS, car l'OP dit être sur OS X qui est l'ancien nom de iOS.
Mais comme beaucoup confondent OS X et Mac OS X, il y a aussi une
possibilité qu'il soit sur Mac OS X.

ca a des chances d'etre faisable a coups de dtrace
egalement, sans avoir a rien developper...



Ce genre de script ne marche heureusement pas sur unix car les scripts
ne gèrent pas les bits de modification de privilège, contrairement aux
binaires purs.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Avatar
espie
In article <4c6d0e8c$0$666$,
Éric Lévénez wrote:
Ce genre de script ne marche heureusement pas sur unix car les scripts
ne gèrent pas les bits de modification de privilège, contrairement aux
binaires purs.



Euh, non, ca ca depend des Unix. Et essentiellement, ca peut marcher
si le systeme et le "shell" savent lire du script sans passer par son
nom. Globalement, s'il y a support pour /dev/fd/*
Avatar
Éric Lévénez
Le 19/08/10 13:41, Marc Espie a écrit :
In article<4c6d0e8c$0$666$,
Éric Lévénez wrote:
Ce genre de script ne marche heureusement pas sur unix car les scripts
ne gèrent pas les bits de modification de privilège, contrairement aux
binaires purs.



Euh, non, ca ca depend des Unix. Et essentiellement, ca peut marcher
si le systeme et le "shell" savent lire du script sans passer par son
nom. Globalement, s'il y a support pour /dev/fd/*



Mac OS X supporte /dev/fd/*, comme tous les GNU/Linux je pense, mais je
ne vois pas en quoi ce support bouche le trou de sécurité des shells
avec bits s.

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

Le 19/08/10 13:41, Marc Espie a écrit :
> In article<4c6d0e8c$0$666$,
> Éric Lévénez wrote:
>> Ce genre de script ne marche heureusement pas sur unix car les scripts
>> ne gèrent pas les bits de modification de privilège, contrairement aux
>> binaires purs.
>
> Euh, non, ca ca depend des Unix. Et essentiellement, ca peut marcher
> si le systeme et le "shell" savent lire du script sans passer par son
> nom. Globalement, s'il y a support pour /dev/fd/*

Mac OS X supporte /dev/fd/*, comme tous les GNU/Linux je pense, mais je ne
vois pas en quoi ce support bouche le trou de sécurité des shells avec bits
s.



Je ne vois pas pourquoi le wrapper devrait etre suid. Il appelle le
programme qui l'est.

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Éric Lévénez
Le 19/08/10 14:38, Jean-Marc Bourguet a écrit :

Je ne vois pas pourquoi le wrapper devrait etre suid. Il appelle le
programme qui l'est.



C'est ce que j'avais supposé par l'explication de l'OP : "ncutil étant
appelé par du code objective C en mode privilégié". Ce programme ncutil
n'étant pas standard sur Mac OS X, je ne le connaissais pas, et comme
les exemples que retournent Google donne des trucs du genre "sudo
ncutil", il y avait de quoi faire la supposition que j'ai faite je pense :-)

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Avatar
espie
In article ,
Jean-Marc Bourguet wrote:
Éric Lévénez writes:

Le 19/08/10 13:41, Marc Espie a écrit :
> In article<4c6d0e8c$0$666$,
> Éric Lévénez wrote:
>> Ce genre de script ne marche heureusement pas sur unix car les scripts
>> ne gèrent pas les bits de modification de privilège, contrairement aux
>> binaires purs.
>
> Euh, non, ca ca depend des Unix. Et essentiellement, ca peut marcher
> si le systeme et le "shell" savent lire du script sans passer par son
> nom. Globalement, s'il y a support pour /dev/fd/*

Mac OS X supporte /dev/fd/*, comme tous les GNU/Linux je pense, mais je ne
vois pas en quoi ce support bouche le trou de sécurité des shells avec bits
s.





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.
Sur un unix recent, 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.
Avatar
Éric Lévénez
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.

Sur un unix recent,



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

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

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.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Avatar
espie
In article <4c6d339c$0$7867$,
Éric Lévénez 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

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.


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)

- un langage "visible" favorise les trous. On sait tres bien que ca n'arrete
pas les pirates. Du reverse-engineering cretin sur du code C compile mal
ecrit va tres vite mettre en evidence des trous. Ca n'est pas tres balaise,
car il n'y a pas besoin de comprendre tout le programme, juste quelques
dizaines d'instructions au bon endroit... il faut juste connaitre un peu
d'assembleur, et savoir un peu ou gratter (ce qui reclame des competences
tres proches de celles qui permettent de debugguer un programme). Pire:
ca s'automatise ! on a pas mal parle il y a quelques mois d'un analyseur
de vulnerabilites dans les patch Windows Update, qui prenait le code binaire,
appliquait quelques patterns bien sentis pour detecter les buffer overflow,
et arrivait dans pas mal de cas a pondre l'exploit correspondant snas
intervention humaine.

Franchement, si j'ai une operation a faire qui s'exprime simplement et de
facon auditable dans un langage de script pas trop mal ecrit, que le script
correspondant va suffisamment vite pour mes besoins, que le code C
correspondant est 4 a 5 fois plus long (et contient donc 5 fois plus de
bugs), je vais choisir le langage de script dans 100% des cas.
1 2