logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 26-11-2023 16:21:10

sylvain_78
Membre
Lieu : Nouvelle Aquitaine
Distrib. : Bookworm
Noyau : Linux 6.1.0-13-amd64
(G)UI : KDE plasma
Inscription : 31-10-2017

[Résolu] Script BASH : sécurisation.

Bonjour,

Dans le script que j'utilise pour réaliser mes synchronisations, je lis les répertoires à synchroniser dans un fichier texte (rep2sync.txt).

Après un rhum bien tassés hier soir (avec modération bien sûr big_smile), je me suis rendu compte qu'il était tout à fait possible de trafiquer mon rep2sync.txt afin de lancer une commande non prévue dans le script. En effet rep2sync.txt est lu ligne par ligne, chaque ligne est stockée dans une variable locale, laquelle est utilisée en argument de rsync.

Si une ligne de rep2sync.txt est du style "/rep/to/sync ; une_commande", je pense que rsync va planter (pas de cible) puis une_commande va être exécutée.

Est-ce bien le cas et si oui comment se prémunir de ce type de faille ?
J'ai pensé à simplement tester la validité du répertoire contenu dans la variable locale, mais :
- c'est une solution dans mon cas d'usage ;
- l'exécution de une_commande pourrait de toute façon être obtenue lors du test en adaptant le texte de la variable (?)

Alors existe-t-il une façon 'clean' de s'assurer que le texte contenu dans une variable ne sera pas interprété ?

Sylvain

Dernière modification par sylvain_78 (27-11-2023 12:04:13)

Hors ligne

#2 26-11-2023 16:36:16

saitama-san
Membre
Distrib. : stable
(G)UI : gnome
Inscription : 28-07-2019

Re : [Résolu] Script BASH : sécurisation.

il suffit de vérifier que la ligne du texte correspond bien à un chemin via la commande 'test'
la variable sera interprété, pas exécuté

après tu peux sécuriser le fichier en adaptant les droits en limitant les modifications
ceci dit, il est fort probable que si tu quelqu'un peut modifier le fichier rep2sync.txt il peut également modifier le script qui vient le lire. dans les deux cas il peut exécuter des commandes.

Hors ligne

#3 26-11-2023 16:55:20

sylvain_78
Membre
Lieu : Nouvelle Aquitaine
Distrib. : Bookworm
Noyau : Linux 6.1.0-13-amd64
(G)UI : KDE plasma
Inscription : 31-10-2017

Re : [Résolu] Script BASH : sécurisation.

Oui, bien-sûr, mais comme indiqué dans mon message il s'agit d'une solution pour mon cas d'usage.

Je souhaite savoir s'il existe une solution plus générique à ce type de souci.

Hors ligne

#4 26-11-2023 18:08:19

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Script BASH : sécurisation.

Pour éviter les problèmes de substitution de variable, il faut commencer par protéger l'utilisation des variables avec des guillemets doubles : "$variable".
Mais je ne pense pas qu'on puisse exécuter une commande arbitraire de cette façon car sauf erreur de ma part les mots et caractères réservés (if, for..., <, >, ;...) ne peuvent résulter d'une substitution de variable.

Autre précaution possible : passer "set -e"  pour arrêter le script dès qu'une commande termine en erreur (code retour non zéro). Attention, cela demande d'adapter la façon de coder et de vérifier ou neutraliser le résultat de toutes les commandes qui peuvent terminer en erreur en utilisation normale, notamment les tests ; par exemple on ne peut plus écrire

[ condition ] && commande


car si la condition est fausse le test termine en erreur. À la place on peut écrire

[ ! condition ] || commande


ou le classique mais plus encombrant

if [ condition ]; then
  commande
fi


Il vaut mieux montrer que raconter.

Hors ligne

#5 26-11-2023 18:31:32

vv222
Administrateur
Distrib. : Debian Sid
(G)UI : sway
Inscription : 18-11-2013
Site Web

Re : [Résolu] Script BASH : sécurisation.

À moins que tu utilises exec ou eval dans tes scripts, il y a très peu de manières d'exécuter par accident le contenu d’une variable comme s’il s’agissait d’une série de commandes.

Jouer sous Debian ? Facile !

Ceterum censeo Barum esse delendam

Hors ligne

#6 27-11-2023 12:09:59

sylvain_78
Membre
Lieu : Nouvelle Aquitaine
Distrib. : Bookworm
Noyau : Linux 6.1.0-13-amd64
(G)UI : KDE plasma
Inscription : 31-10-2017

Re : [Résolu] Script BASH : sécurisation.

Bonjour à tous et merci pour vos réponses !

Un petit test rapide m'aurait sans doute évité de poser cette question stupide... mais j'avais un doute. Car j'ai appris il y a vingt ans qu'une faiblesse de PHP permettait facilement de faire tomber une base de données à partir de l'utilisation sans contrôle dans un code SQL d'une variable saisie dans un formulaire. J'ai fait un parallèle malheureux...

Bonne journée !
Sylvain

Hors ligne

#7 27-11-2023 14:26:52

vv222
Administrateur
Distrib. : Debian Sid
(G)UI : sway
Inscription : 18-11-2013
Site Web

Re : [Résolu] Script BASH : sécurisation.

Cette question n’était pas stupide, il y a des langages où c’est un vecteur d’attaque fréquent. Les injections SQL sont un bon exemple.

Jouer sous Debian ? Facile !

Ceterum censeo Barum esse delendam

Hors ligne

Pied de page des forums