[lea-aide] La securite des coquillages

[Emmanuel Fleury < >]

Bonjour,

Cette récente discussion m'a un peu interpellé, comment programmer des
shell-scripts qui soient relativement robustes aux attaques et quelles
sont les recommandations à donner pour ceux qui veulent manipuler des
données sensibles (mots de passe, fichiers importants, etc) via des
shell-scripts ?

Après un petit tour sur le Web le constat s'impose, il y a relativement
peu de littérature sur le sujet. À noter tout de même, une section du
"Secure Programming for Linux and Unix HOWTO" de David A. Wheeler est
consacrée aux spécificités du langage shell (et je m'en suis inspiré
pour la suite).

Voir:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/shell.html

Voici donc quelques points importants à garder en mémoire et quelques
règles à appliquer qui pourraient aider ceux qui se posent la question
de programmer leur shell-scripts de façon robuste.

1) Les principales faiblesses du shell
--------------------------------------
Le shell est un langage qui ne possède pas ou peu de notion de type de
données, les vérifications y sont donc extrêmement rares et peuvent
souvent porter à confusion sur ce que fait réellement votre programme.
Le plus souvent (et ce même pour les utilisateurs averti) la réalisation
d'un programme se fait par une succession d'essais/erreurs qui abouti à
un résultat final souvent dont le bon fonctionnement n'est absolument
pas garanti lorsqu'on pousse le script hors de ses retranchements.

La première solution est de bien connaître le shell. Une lecture des
célèbres Bash-Beginners-Guide et Advanced-Bash-Scripting-HOWTO arrive
déjà au bout de pas mal de réticents (voir:
http://tldp.org/LDP/Bash-Beginners-Guide/html/ et
http://tldp.org/LDP/abs/html/).

Mais lorsqu'il s'agit de debugger un script, on en est pas moins
ennuyé... (voir: http://tldp.org/LDP/abs/html/debugging.html).

Cependant, on peut utiliser 'bashdb' (bash debugger, voir:
http://bashdb.sourceforge.net/bashdb.html) qui permet de tracer
complètement l'exécution du script shell comme on le ferait avec gdb et
un programme compilé et comprendre beaucoup plus en profondeur ce qui se
passe réellement.

Une fois une bonne compréhension de ce que fait le shell acquise, il
faut aussi assimiler le fait que le shell a été crée et a évolué dans
l'idée d'automatiser la tâche pour un utilisateur qui serait présent
lorsqu'il exécute le script... C'est à dire que c'est plus un langage
pour concevoir des macros que pour concevoir des programmes automatiques
qui réagiraient et traiteraient par eux-même des cas problématiques lors
de l'exécution du script. Pour preuve, le manque de codes existants
concernant le traitement des erreurs et des exceptions en script-shells.
Alors que la commande 'trap' permet de faire pas mal de choses, même si
elle reste assez limitée.

Voir:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html
http://fvue.nl/wiki/Bash:_Error_handling
http://assela.pathirana.net/Bash_disaster_prevention

Mais, finalement, les programmes shells, pour peu qu'on les exécute dans
un environnement contrôlé et que l'on maîtrise un peu finement ce qui se
passe restent des programmes robustes aux attaques (il n'y a pas de raison).

Pour résumer, le gros problème des scripts-shell restent tout de même:

a) Le peu de vérification des types et des flots de données
b) Le manque de visibilité de l'exécution interne d'un script
c) Le manque de traitement des erreurs et des exceptions lors de
l'exécution du script


2) Sous quelles conditions mon script sera-t-il 'fiable' ?
----------------------------------------------------------
Un certain nombre de conditions doivent être rassemblées, et j'insiste
sur le fait qu'elles sont loin d'être automatiques.

En tout premier lieu, il faut une maîtrise complète de l'environnement
de départ (c'est à dire des valeurs des variables de départ comme, par
exemple, le PATH, le HOME, etc). En fait mieux vaut partir d'un
environnement vide puis mettre soit-même les valeurs voulues aux variables.

Du point de vue de l'implémentation nettoyer l'environnement n'est pas
si simple que cela. À priori, comme en ligne de commande on fait:
'env -i nom_du_script', on s'attendrait à pouvoir écrire en début de
fichier quelque chose comme:

#!/usr/bin/env -i /bin/bash

Mais mon système refuse (il semble qu'après un sha-bang on ne puisse
mettre qu'une seule option.

La solution la plus satisfaisante que j'ai trouvée était donc de lancer
le script en environnement protégé via: env -i ./script.sh

Mais d'autres solutions (plus 'sales' à mon humble avis):
http://crashingdaily.wordpress.com/2008/03/07/clearing-environment-variables-in-bash-scripts/


En second lieu, il faut maîtriser la portée des différentes variables
d'environnement et plus particulièrement celles qui contiennent de
l'information sensible...

Par exemple, on n'abusera pas de la commande 'export' qui permet de
diffuser une variable d'environnement à tous les fils d'un processus...
Pour ce qui est du mot de passe, il est seulement nécessaire de
l'utiliser ponctuellement et restreindre la portée de la variable shell
est tout de même important.

Ensuite, nettoyer l'environnement de départ n'aurait servi à rien si
vous laissez des moyens pour un attaquant extérieur d'injecter des
commandes dans votre script. Vérifiez donc les fichiers que vous ouvrez,
les variables que vous lisez, et protégez les avec des double-quotes
(utilisez "$1" et non $1, appelez les commandes Unix classiques avec
l'option '--' juste devant les variables shell donnant les arguments
pour désactiver l'interprétation des options qui auraient pu s'y
glisser, etc...).

Enfin, préférez l'utilisation d'un shell restreint (restricted shell,
voir 'man rbash') à un shell complet.

Voila, ce ne sont que quelques conseils qui sont applicables seulement
lorsque vous codez quelque chose de _sensible_ en shell (ce qui devrait
être rare).

Pour finir, je serai curieux de savoir comment faire pour lancer
proprement un script en nettoyant l'environnement (j'ai eut beau
chercher longtemps et faire des expérience par moi-même je n'y arrive
pas... frustrant !!!).

Cordialement
-- 
Emmanuel Fleury

Most people, I think, don't even know what a rootkit is,
so why should they care about it?
  -- Thomas Hesse (President of Sony BMG about the Sony CD rootkit)