Récupérer commande system

Bonjour,

J'essaie de m'amuser avec les commandes système sauf que je n'arrive pas à faire ce que je veut.

Si je fais :

Code:

---

1 2 3

int valeur; valeur = ('dir'); cout << valeur ;

---

J'obtiens un chiffre ( souvent un : 1 ). Normal car je stocke la valeur dans un int, sauf que j'ai beau cherché je ne vois pas comment faire pour qu'en faisant un cout j'ai le retour de ma commande systeme, au lieu que ma variable stocke un chiffre je voudrais qu'elle me stocke tout ce que je vois affiché à l'écran quand je fais cette commande dans un cmd.

Merci d'avance de vos aides, cordialement Spiritus,

Oubliez la fonction "system", c'est une cochonnerie.
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Bonjour.

Code:

---

1 2	valeur = ('dir');

---

Ca marche ce code ? :weird: Ce n'est pas plutôt

Code:

---

1 2	valeur = system("dir");

---

La fonction system permet de faire exécuter par l'interprète de l'OS la commande passée en paramètre. La chaîne passée en paramètre doit être l’expression complète, avec options et arguments, d’une commande légale pour le système utilisé (tiré du polycopié du cours sur le langage C, Par Henri Garreta). Et comme l'a dit bacelar, il n'est pas recommandé d'utiliser cette fonction. La fonction renvoie la valeur résultat de la commande exécutée, donc le "1" est le résultat de l’exécution de la commande dir par l'OS.

Si vous voulez récupérer l'affichage généré par dir, vous pouvez procéder comme suit:

Code:

---

1 2 3 4 5 6

char *nomfichier = "c:/monbazar/foo.txt"; // le dossier c:\monbazar doit exister au préalable int i; i = system("dir >> c:/monbazar/foo.txt"); // Le fichier c:/monbazar/foo.txt contient maintenant le résultat de l'affichage de dir, // vous pouvez l'afficher comme vous le voulez.

---

Citation:

---

Envoyé par bacelar

Oubliez la fonction "system", c'est une cochonnerie.
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

---

Du code non portable aussi.
system est très bien si on veut juste lancer un programme sans se soucier de la sortie.

En lancer plein de virus par la même occasion.
Laissez "system" mourir en paix.

Je m'en suis servi pour bencher des programmes et pour lancer gnuplot, j'ai jamais eu de souci.
system doit (peut-être) être utiliser avec soin, mais n'est pas forcément à bannir (?) (J'ai pas trouvé grand chose via Google sur la dangerosité de system)

En fait, un programme utilisant system est simple à violer, il suffit de modifier intelligemment son PATH, pour mettre le programme à exécuter devant.

Par exemple, supposons un programme gentil faisant juste appel à system("gnuplot machin truc");.
Il suffit de créer un programme que j'appelle gnuplot, et de faire en sorte que system() trouve le mien plutot que le programme souhaité pour être exécuté.

Maintenant, je peux aussi m'amuser à remplacer des programmes plus important, comme rm, pour pouvoir conserver les fichiers "secrets" d'un programme mal sécurisé.

Sachant qu'il faut trois fois rien pour savoir quelles commandes sont appelées par system.

C'est tout à fait exact, sur le plan sécu, c'est une vraie passoire. Après, c'est à mettre en perspective de l'utilisation qui en est faite : si c'est un exécutable privé utilisé pour faire des calculs en one shot et tracer les résultats, ce n'est pas particulièrement dangereux.Si un attaquant a accès au PATH, il peut faire des trucs bien pires qu'utiliser la vulnérabilité introduite dans le soft de l'op ! Il faut être prudent quand il s'agit d'un logiciel distribué massivement ou exécuté comme un serveur, et je ne crois pas que ça soit le cas ici.

Je pense que si un type modifie ton PATH (ou l'exécutable lancé par system), tu as d'autres soucis avant de te préoccuper des programmes lancés avec system.

Pas besoin de modifier le PATH, CMD.EXE cherche dans le working directory, et dans tout un ensemble de répertoire système pas forcement très safe pour les commandes "built-in" avant d'utilisez le PATH, et il a une interprétation vraiment très original mais pas très safe d'interpréter les espaces dans cette variable d'environnement.
C'est une passoire sécuritaire, un boulevard à virus.
Ici, je parle de la fonction Win32 system, je ne sais pas si std::system de la STL a les même faiblesse (plus lié à CMD.EXE qu'à l'API système).

Bonjour,

En quoi un createProcess (ou un exec* qui eux sont posix 2001 et 2008) serait-il plus sûr qu'un system :koi:

Ca n'utilise pas les "fonctionnalités" douteuse de CMD.EXE.

Mais comment trouvent-ils l'application, puisque tu ne peux pas décemment utiliser un chemin absolu?
De la même manière que CMD.exe

Le PATH et la base de registe, pas d'interprétations vaseuses de commande "built-in" (sans l'être vraiment) ou de chemins avec des espaces.

Et le PATH est une variable d'environnement de l'appel au programme, modifiable aisément (il suffit de le surchargé lors de l'appel)

Le PATH, ça sera celui du processus parent. Si le processus parent n'est pas compromis, il n'y a pas de problème.
C'est l'utilisation de "system" qui permet à l'attaquant de faire la fête et de s'introduire dans le contexte de sécurité "privilégié" juste en touchant à des répertoires non safe car n'étant que des répertoires de transites du PATH et non des cibles du PATH.
L'utilisation de "system" est le maillon faible ici.

J'avoue que je n'ai pas trop compris ton explication.

En gros, si j'ai un PATH="C:/d1/d2/d3/toto" ou PATH="/d1/d2/d3/toto", le répertoire "toto" est protégé mais pas les répertoires d1, d2, d3.
Or il est possible en touchant les répertoires d1, d2 ou d3 de provoquer une faille de sécurité ?

Si PATH="C:/d1/d21 d22/d3/toto"
Est-ce que t'accepterais qu'un programme d22.exe ou d22.com ou d22.bat (et autres .pif) dans d21 soit exécuté à la place de l'exécutable dans toto ? :aie:
Moi, pas. :weird:

Hein ?
C'est bizarre.

Normalement les chemins ne sont pas séparés par des ';'/':' dans le path ?
Tu veux dire que pour system, quand il voit un espace, il considère que le chemin s'arrête à l'espace ?

C'est spécifique à Windows ou c'est aussi le cas sous Linux ?

C'est pas system en lui même, c'est CMD.EXE qui fait sa tampouille.
Je ne pense pas que les shell UNIX/Linus aient les mêmes problèmes, mais peut-être d'autres, qui sait.

Cela m'a pourtant tout l'air d'un bug tout bête et relativement facile à corriger.

CMD.exe n'a tout de même pas été écrit par n'importe qui, cela m'étonne d'autant plus que c'est un "bug" qui est connu, qui touche la sécurité, tout bête mais qui portant n'a toujours pas été corrigé :?.

A moins que ce comportement soit justifié d'une quelconque manière par Microsoft ?

c'est la base du spoofing, qui existe dans les deux systèmes, unix et linux.

suppose un programme p quelconque (p ou p.exe), utilisant bidule (.exe)

la commande p arguments lance le programme
Mais PATH=/cheminPourri/:$PATH p arguments lance le programme permet d'exécuter p en cherchant d'abord bidule dans /cheminPourri/, et à une syntaxe près, c'est aussi faisable avec windows.

C'est par exemple utilisable pour remplacer une lib par une autre (avec LDPATH)

Citation:

---

Envoyé par leternel

Mais PATH=/cheminPourri/:$PATH p arguments lance le programme permet d'exécuter p en cherchant d'abord bidule dans /cheminPourri/, et à une syntaxe près, c'est aussi faisable avec windows.

---

Si j'ai bien compris ce que dit bacelar, c'est encore pire, si :

Code:

---

PATH=unChemin:unAutreChemin

---

Mais si unChemin comporte un espace : unChemin="partie1 partie2", il va aussi rechercher dans "partie1" s'il n'y a pas l'exécutable. C'est un comportement très étrange.

Il faudrait que je teste sur un Windows.