liste des mots dangereux pour exec ou eval

Bonjour tous,

je souhaiterai utiliser la commande "exec" ou eventuellement "eval" pour une application particulière où j'execute le contenu d'un fichier texte et j'aimerais savoir qu'elle est la liste des mots qui peuvent mener à une faille de sécurité dans mon code (afin de ne pas autoriser l'execution si je trouve un de ses mots). (dans mon code les librairies numpy et scipy on été importé)

La chose qui me paraît importante c'est de ne pas autoriser l'execution si les mots "os" ou "import" sont trouvés dans le fichier mais je pense qu'il y a plein d'autres choses auxquelles je ne pense pas, pourriez vous me dire les choses qui sont "dangereuses" en python ?

Par exemple existe t il une commande permettant d'aller sur internet/serveur externe? j'aimerais bien la désactiver

merci pour vos renseignements

bonne journée

Salut,

Lorsque des experts vous ont déjà répondu dans un autre forum qu'essayer de sécuriser exec était une mauvaise idée...
Quelle genre de réponse espérez vous en postant la question dans un autre forum?

Les seules limites du programmeur sont celles de son imagination.
C'est ce qui fait qu'"exec" est interdit sauf à démontrer qu'on ne peut faire autrement *et* être certain du code exécuté via ce mécanisme.

Le pourquoi du comment est lié à ce qu'est un programme.
C'est un automate à états finis dont on sait prédire voire démontrer le comportement.
C'est l'aspect "fini" qui rend utile l'écriture d'un plan de test qui démontrera que le code fait bien ce qu'on attend.
A partir du moment où on applique exec à n'importe quel texte entré par un utilisateur, comment tester que ce n'importe quoi ne produira pas ce que vous ne voulez pas?
Techniquement, pas facile de définir "ce que vous ne voulez pas" et encore moins facile de démontrer qu'on ne pourra l'atteindre via "n'importe quoi'.
Construire un plan de test montrant que... est alors impossible.
Et sans pouvoir "tester", impossible de dire "ça ne fera pas ce que je ne veux pas".

Bon courage

- W

merci
A+

salut
Lisez ici https://2013.picoctf.com//problems/pyeval/stage1.html

Bonjour,

J'ai un peu travaillé cette question, et je confirme que c'est quasi impossible de rendre sécurisé exec et eval si on veut lui faire exécuter n'importe quoi écrit par n'importe qui.

Pour prendre simplement un exemple, eval ne permet que de calculer une expression et renvoyer le résultat, genre "eval('2+3') => 5". Malheureusement, il y a des astuces pour lui faire importer un module et en exécuter des fonctions. On peut donc lui faire exécuter n'importe quoi, y compris effacer le disque...

Et si on peut faire ça avec seulement eval, alors avec exec...

Salut,

Citation:

---

Envoyé par tyrtamos

J'ai un peu travaillé cette question, et je confirme que c'est quasi impossible de rendre sécurisé exec et eval si on veut lui faire exécuter n'importe quoi écrit par n'importe qui.

---

Techniquement il est possible de réaliser la condition "être certain du code exécuté via ce mécanisme".
L'idée est de limiter le code qui sera exécuté en analysant son abstract syntax tree (voir le module ast).
Plutôt qu'essayer de boucher un radeau qui fuit de tous les côtés, on interdira tout sauf... quelques constructions permises qu'on pourra examiner.
Comme parser l'AST se fait avant l'exécution du code via "exec", çà peut le faire.
Une autre technique qu'on peut aussi utiliser (en sus pour bétonner le truc) est la trace des instructions (via le module trace).

L'un dans l'autre on peut définir un sous ensemble de constructions permises (et interdire toutes les autres) et on aura la possibilité de "tester".

Mais c'est du boulot et çà demande la maîtrise de techniques difficilement accessibles aux débutants.

- W

Bonjour,

Merci wiztricks. Effectivement "parser" le code présenté à exec et eval avec ast est une idée intéressante. Mais je vois pas encore la complexité de la chose. Je vais creuser dans cette direction à l'occasion.

Jusqu'à présent pour eval, j'envisageais plutôt de neutraliser les fonctions dangereuses, et donc les importations, avec quelque chose comme:

Code:

---

1 2	def __import__(nommodule=""): pass

---

Mais je ne suis pas allé plus loin pour l'instant.

Citation:

---

Envoyé par tyrtamos

Merci wiztricks. Effectivement "parser" le code présenté à exec et eval avec ast est une idée intéressante. Mais je vois pas encore la complexité de la chose. Je vais creuser dans cette direction à l'occasion..

---

Ce qui est modérément compliqué est de comprendre l'AST.
Il faut avoir trempé dans les techniques de compilation pour ne pas s'y perdre.
Ensuite, il faut définir le sous-ensemble de Python "autorisé" qui ne soit pas trop restreint pour rester fonctionnel *et* s'assurer qu'on va pouvoir contrôler que le code soumis plus tard à "exec" reste "sous contrôle".

Si on reprend le contexte du PO, il ne suffit pas d'interdire "import os" pour empêcher X, Y d'accéder à la bibliothèque "os".
Sachant que numpy est dans le "globals()", on peut récupérer "os" via ce qui est importé dans des s/modules comme numpy.testing.tools.os.
Et getattr permet d'en opacifier l'accès:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

>>> data = '''s = '%s%s' % ('o', 's') ... mm = getattr( np.testing.utils, s) ... nm.remove('*')''' >>> ast.dump(ast.parse(data)) "Module(body=[Assign(targets=[Name(id='s', ctx=Store())], value=BinOp(left= Str(s='%s%s'), op=Mod(), right=Tuple(elts=[Str(s='o'), Str(s='s')], ctx=Load()))), As sign(targets=[Name(id='mm', ctx=Store())], value=Call(func=Name(id='getattr', ct x=Load()), args=[Attribute(value=Attribute(value=Name(id='np', ctx=Load()), attr ='testing', ctx=Load()), attr='utils', ctx=Load()), Name(id='s', ctx=Load())], k eywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=N ame(id='nm', ctx=Load()), attr='remove', ctx=Load()), args=[Str(s='*')], keyword s=[], starargs=None, kwargs=None))])"

---

Si on veut tout interdire, c'est pas compliqué.
Par contre, si on veut "ouvrir" intelligemment, il faut évaluer des branches de l'arbre.
La complexité devient alors intéressante.

- W