protection contre injection shell

Version imprimable

19/11/2018, 16h49
Elianora la blanche

protection contre injection shell

Bonjour,

je travaille actuellement sur un projet (interne) pour lequel certaines fonctions php (type exec, system, etc) sont autorisées dans php.ini car utilisées dans le code, légitimement (essentiellement pour exécuter des scripts perl).
Dans le même projet, il y a une fonctionnalité permettant à un utilisateur de saisir un script shell dans un textarea ; ce contenu, stocké en bdd, sera ensuite exécuté sur une machine (autre que le serveur web) donc ne peut/doit pas être trop "nettoyé".
Devant un tel fonctionnement (qui, j'en ai bien conscience, est un trou de sécurité béant ^^), comment éviter au max les soucis de type injection php / shell / autre (quoi ?) ?
Je n'ai jamais touché à un système aussi délibérément "ouvert" et comme on nous rabâche les oreilles à propos de sécurité au niveau hiérarchique (ce que je trouve pertinent par ailleurs ^^), je voudrais bien faire un truc propre

l'enregistrement en bdd passe par des requêtes préparées mais ce n'est pas l'injection sql qui m'inquiète le plus dans ce cas précis

comment m'assurer du bon fonctionnement du formulaire ? que tester / nettoyer / transformer ?
j'ai essayé de mettre un truc du genre

Code:

exec('whoami')

dans le champ et ça ne fait rien mais ça me semble léger comme vérif ^^

merci d'avance,

NB : il y a quand même plusieurs niveaux de protection avant d'arriver jusqu'à ce formulaire mais comme le dit notre CSSI "une chaîne a la force de son maillon le plus faible", je ne veux pas être le maillon faible :P

EDIT : projet développé sur un framework maison librement inspiré de Zend et Symfony
19/11/2018, 19h46
Tsilefy

À partir du moment où tu autorises un utlisateur à saisir un script shell dans un textarea pour l'exécuter plus tard, il n'y a pas grand-chose à faire, à part faire une liste blanche de toutes les commandes autorisées, si c'est possible.

Autrement, il faut verrouiller l'accès avec une restriction par IP et/ou par 2FA.
19/11/2018, 21h29
cavo789

Bonsoir

Absolument d'accord avec Tsilefy : n'autoriser que certaines valeurs prédéfinies (principe de la liste blanche).

En aucune manière autoriser que quelqu'un encode quelque chose car je pourrais p.ex. tenter un exec(base64_decode('BLA BLA BLA')) c'est-à-dire tenter de passer outre tes contrôles.

Je comprends bien que ces formulaires sont strictement accessible à certains utilisateurs, que tu es sur un réseau sécurisé, etc. mais ouvrir la possibilité de taper des lignes de commandes, c'est quand même sacrément risqué.

Dans l'hypothèse où quelqu'un encode (volontairement ou pas) un code qui va détruire des données, quel serait ta responsabilité ? Si tu réponds : on risque de me tirer l'oreille voire pire; à ta place, je ne coderais pas une telle interface.

Ne pourrais-tu pas restreindre le risque avec une liste blanche; des scripts que tu ajouterais toi-même, que tu aurais validé, relu, etc. bref sur lequel tu aurais apposé un "OK; pas de souci" ?

Bonne soirée.
20/11/2018, 09h41
Elianora la blanche

merci pour vos réponses, je m'en doutais un peu ^^

on avait plutôt une liste noire : certaines commandes étaient refusées mais le demandeur a dit : "c'est pas assez sécurisé" (sic) (en plus, les regex étaient foireuses et refusaient des chaines de caractères légitimes)
la liste blanche, d'ici que les utilisateurs nous listent tout ce à quoi ils doivent accéder, on y est encore dans 3 ans... :P

et on ne peut pas ne pas faire cette fonctionnalité ^^ l'appli en elle-même est un trou de sécurité de par ce qu'elle est censée faire, on le sait bien
de même impossible de pré-valider, les scripts sont entrés par des gens dont on (l'équipe de dév de l'IHM) ne connait pas le boulot, ni pourquoi ils le font, ni comment, encore pire que la liste blanche, c'est inenvisageable

en parallèle, sur l'appli, il y a un chantier de sécurisation des accès, avec clé de cryptage sur un support physique, faut quand même déjà arriver jusque là

sinon, est-ce qu'il ne serait pas plutôt possible de lancer "nos" scripts perl sans passer par exec, system et tutti quanti et donc de mettre ces fonctions PHP en ignore list dans le php.ini ?
20/11/2018, 19h56
Tsilefy

Tu as 2 soucis donc. Le textarea est insurmontable (en tout cas dans PHP). Mieux vaut blinder les permissions d'accès.

Le lancement de scripts perl, ça dépend. Quelles sont les conditions de déclenchement de ces scripts? Est-ce que c'est automatique ou il faut une action humaine / extérieure au serveur? Est-ce que exec reçoit le nom du script grâce à des inputs utilisateurs?
21/11/2018, 08h42
bretus

Bonjour,

Citation:

Envoyé par Elianora la blanche

Je n'ai jamais touché à un système aussi délibérément "ouvert" et comme on nous rabâche les oreilles à propos de sécurité au niveau hiérarchique (ce que je trouve pertinent par ailleurs ^^), je voudrais bien faire un truc propre

Il y a pourtant pas mal de système de systèmes qui permettent in-fine d'exécuter des scripts shell utilisateur sans nettoyage :

- Les systèmes qui te permettent de créer une VM en ligne
- Les éditeurs de code en ligne permettant l'exécution (ex : https://repl.it/repls/LovableBurlyFlatassembler)
- Les outils d'intégration continue (jenkins, Travis CI, etc.)
- Les outils de déploiement (puppet server, chef server, etc.)
- ...

Niveau sécurité, je vois globalement deux stratégies sur ces outils :

- Restriction de l'environnement d'exécution (droit utilisateur restreint, isolation réseau, etc.)
- Restriction des utilisateurs autorisés à exécuter ces scripts (avec éventuellement des mécanismes de validation)

La base pour choisir la bonne stratégie, ça va être de commencer par répondre à la question : A quoi servent ces scripts bash?

Si tes scripts doivent permettre à quelques utilisateurs de supprimer des fichiers, tu ne sécuriseras pas de la même façon que si tes scripts doivent uniquement permettre à de nombreux utilisateurs de faire des analyses sur le contenu de ces fichiers.

Plus globalement, je t'inviterais bien à parcourir les principes de la méthode EBIOS qui oblige à prendre du recul pour bien "identifier les événements redoutés" afin de définir les bonnes "mesures de sécurité" (en bonus, niveau hiérarchie, un cadre ça rassure)
21/11/2018, 10h55
Elianora la blanche

le principe de l'appli est de récupérer des config de machines distantes (et faire qq autres trucs), bcp d'utilisateurs y ont accès et peuvent faire pas mal de choses (c'est pour ça que c'est très "ouvert")

typiquement, les scripts shell que les utilisateurs vont saisir seront une liste de cat, grep, etc
et les scripts perl permettent grosso modo de contacter lesdites machines pour lancer ces scripts shell (y aussi de l'envoi de mail et du traitement de données provenant de la base, je sais pas pourquoi c'est fait en perl et pas en php mais je vais pas le changer, pas le temps)
certains sont lancés sur action utilisateur sans paramètre saisi manuellement, certains avec et certains sont lancés automatiquement (cron)
bref un joyeux bazar quand même

y a aussi 2-3 exec qui servent à manipuler des fichiers sur le serveur web lui-même (déplacement dans l'arbo, déplacement de fichiers, archivage) => ça, il est probablement possible de le faire avec des fonctions php et sans exécuter du shell
mais c'est un gros chantier donc ça prend du temps, donc ça coûte de l'argent, donc on le fera pas (enfin, vous voyez le genre "on veut tout pour rien" ^^)
le blindage d'accès est déjà en place et on va en ajouter une couche

cela dit, je pense qu'il y a une vraie réflexion à mener par rapport à ça et pas juste mettre en place une mini protection sur les 2 textareas concernés (même si, bien sûr, c'est ça que les utilisateurs voient et pas tout ce qui est derrière) ^^

je vais déjà essayer de n'utiliser qu'une seule fonction "système", ça permettra de virer les autres (ça change pas fondamentalement le truc, mais ça forcera les futurs développeurs à se demander pourquoi c'est bloqué)
22/11/2018, 09h07
bretus
Citation:

Envoyé par Elianora la blanche

cela dit, je pense qu'il y a une vraie réflexion à mener par rapport à ça et pas juste mettre en place une mini protection sur les 2 textareas concernés (même si, bien sûr, c'est ça que les utilisateurs voient et pas tout ce qui est derrière) ^^

C'est se poser réellement la question du "autre" à côté des injections sql et php :

- Accès à des données sensibles
- Corruption des données de la base
- Corruption des données du serveur
- Installation d'une backdoor
- Envoi d'un email d'insulte aux clients
- ...

Après, tout comme tu fais des requêtes préparées pour éviter des injections SQL, tu proposes des mesures en face des risques :

- S'assurer que l'on a bien une traçabilité sur les scripts
- Faire valider les scripts par un administrateur
- Compte spécial pour les accès à la base de données (lecture seule, pas d'accès aux tables sensibles, etc.)
- Restriction de l'environnement d'exécution des scripts (droits sur les fichiers, chroot)
- Distinguer deux fonctions dans l'application : ajouter un script en décrivant ses paramètres et exécuter un script avec des paramètres
- Compiler les bash en PHP pour autoriser seulement une liste de commandes autorisées :
Code:

1 2 3 4 <command1> <param1> <param2> ... <command2> <param1> <param2> ... # moins trivial si tu dois gérer des if...
- ...

Dès lors, choisir si on met en place telle ou mesure en fonction du coût ou de l'impact (système moins ouvert, utilisateurs qui doivent attendre des validations,...), ça revient à celui qui doit choisir d'assumer ou non le risque...