Sécuriser la Slackware avec exec-shield.

Merci de faire parvenir en anglais à l'auteur vos questions et commentaires relatifs à la version originale de ce document à l'adresse <kfitzner CHEZ excelia POINT org>.

N'hésitez pas à faire parvenir vos commentaires et suggestions concernant l'adaptation française de ce document au projet Traduc.org à l'adresse : <commentaires CHEZ traduc POINT org>.

Ou à Lisa via le formulaire : http://lisa.oryma.org/alive.

La version originale la plus récente de ce document est disponible à l'adresse : http://www.userlocal.com/articles/securingslackware.php.

Le Saint Graal de nombreux pirates essayant d'avoir accès à un système est l'attaque à distance par débordement de mémoire (buffer overflow). Avouons-le, ils cherchent avant tout un PC (Personnal Computer, ordinateur personnel ) sous MS Windows non protégé par un pare-feu. Mais l'attaque à distance par débordement de mémoire arrive (en quelque sorte) en second. Cet article présentera une méthode pour aider à se protéger de ce type d'attaque sur un système Slackware Linux en utilisant le système spécial appelé exec-shield. Son installation se déroulera en deux phases. La première phase est d'installer la rustine (patch) exec-shield pour le noyau. La seconde est de remplacer quelques paquets Slackware par ceux fonctionnant avec exec-shield.

Avant d'expliquer comment se protéger contre ce type d'attaques, il est utile d'examiner en quoi elles consistent. Et ce qu'elles impliquent pour un système non protégé.

Illustration 1 - Une Pile normale

Lorsque un développeur écrit un programme, il a souvent besoin d'allouer de la mémoire pour contenir les informations utilisées par le programme. Cette mémoire temporaire, appelée tampon (buffer), est utilisée pour conserver les données jusqu'à ce que le programme sache quoi en faire. Par exemple, un serveur web peut utiliser cette mémoire afin de conserver l'adresse Internet (URL) que le navigateur demande. Le navigateur envoie l'adresse au serveur web, qui la stocke temporairement dans le tampon, puis il la traite afin de trouver ce que le navigateur demande.

De plus, les développeurs utilisent souvent une zone appelée pile (stack) pour créer ces tampons temporaires. La pile d'un programme est une "zone de travail" temporaire de taille fixe utilisée par les programmes pour stocker les variables. Ils font appel à la pile parce qu'elle est orientée de haut en bas, à l'inverse de la mémoire en temps normal. La mémoire est habituellement utilisée du premier au dernier, de bas en haut. La pile est utilisée de haut en bas. Déposer une donnée sur la pile est comme déposer une autre assiette sur une pile d'assiettes, la dernière assiette posée est la première assiette enlevée (de temps en temps référée comme -LIFO-, last-in first-out). De plus pour conserver les variables, la pile a pour habitude de conserver l'adresse mémoire de retour lorsqu'un programme entre dans un sous-programme. Ainsi pour un programme entrant dans une procédure, l'adresse courante est conservée afin de permettre le retour au programme principal à la sortie du sous-programme.

Parce que la pile a une taille finie, les développeurs n'aiment pas gaspiller son espace. Donc lorsqu'un tampon est nécessaire, les développeurs créent un tampon suffisamment grand pour contenir la plus grosse donnée allant dans cet espace, mais pas plus grand. Dans le cas de notre serveur web, une longue adresse Internet est généralement de l'ordre de quelques centaines d'octets. Quelques adresses contiennent les informations provenant de formulaire, les développeurs peuvent ainsi créer un tampon de deux ou trois kilo-octets. Certains navigateurs ne traiteront pas une adresse plus longue que cela. La pile du serveur web lorsqu'il exécute une procédure pour traiter l'adresse peut ressembler à l'illustration 1. La pile grossit vers le haut, comme une pile d'assiettes. Conséquence, l'adresse de retour qui était placée en haut de la pile, en premier, est maintenant placée -sous- le tampon et d'autres variables utiles à la procédure.

Illustration 2 - Pile après une attaque réussie

L'attaque par débordement de mémoire fonctionne en essayant de remplir le tampon avec plus d'informations que le développeur n'en prévoit dans son code. Si le programme ne vérifie pas la taille des données entrantes avant de les copier dans son tampon, il est alors vulnérable. En conséquence une adresse spécialement travaillée pourrait remplacer l'adresse de retour par sa propre adresse, et même par un code malicieux usurpant ainsi le programme. Un programme ainsi usurpé peut être utilisé par l'attaquant afin de faire tout ce que le propriétaire du programme peut faire. Si le programme est exécuté en root, alors une attaque peut donner le contrôle complet sur votre système à l'attaquant.

Dans le passé, les programmes qui étaient vulnérables à de telles attaques l'étaient parce que les développeurs - honnêtes - qui les écrivaient ne pensaient jamais que des personnes malhonnêtes pouvaient attaquer leur programme. Si les spécifications disaient que la taille maximale d'une donnée est de tant d'octets, alors c'est ce que le développeur allouait. Il ne peut pas y avoir plus que cela, parce les spécifications disent qu'il ne peut pas. Il n'y a donc aucune raison de gaspiller de la mémoire pour un tampon plus grand. Ou encore de gaspiller du temps processeur pour faire des vérifications spéciales sur la taille des données en entrée. Même aujourd'hui avec l'importance d'écrire des programmes qui soient sécurisés, les vulnérabilités prospèrent. De temps en temps elles sont dans une partie de code qui est héritée du temps où les gens ne pensaient pas en de tels termes. D'autres fois c'est simplement un développeur qui a fait une petite erreur, ou qui oublie de penser en terme de sécurité. Cela demande seulement un seul de ces cas pour que le programme soit vulnérable à ce type d'attaque. Un rapport suggère qu'un PC vulnérable connecté à l'Internet sera compromis en moyenne en 20 minutes. Un autre rapport suggère que c'est seulement en quatre minutes. Ceci ne signifie pas que toutes les vulnérabilités soient des débordements de mémoire. Par exemple, le pare-feu de ce PC sous Slackware enregistre plusieurs tentatives de débordement de mémoire chaque jour dans son fichier de log du serveur web.

La meilleure façon de se protéger contre une attaque par débordement de mémoire est d'utiliser des logiciels protégés contre ce genre d'attaque. Faire un audit de sécurité complet sur le code de tout les logiciels actifs n'est en général pas dans les capacités des utilisateurs. Cependant, il est possible à tout utilisateur d'éteindre tous les services dont ils n'ont pas besoin. La première règle de base concernant les services tournants sur tout PC connecté à l'Internet devrait être "si vous n'en avez pas besoin, alors ne l'utilisez pas !". La Slackware est particulièrement efficace pour ne pas activer des services Internet par défaut. Si votre PC Linux est connecté à l'Internet, jetez un coup d'oeil au fichier /etc/inetd.conf. Ce fichier contrôle quels services Internet sont supportés via le super-serveur inetd. Parcourez votre fichier de configuration et cherchez les services que vous n'utilisez pas. Si vous ne savez pas si vous en avez besoin, désactivez-le. Un attaquant ne peut pas attaquer un service absent.

Ingo Molnar, un développeur (hacker, du bon type) du noyau travaillant pour Red Hat, a écrit une rustine pour le noyau Linux. Elle est conçue pour vous protéger contre la majorité des attaques par débordement de mémoire. Elle a été faite de manière à vous protéger contre celles-ci même si vous utilisez des logiciels qui pourraient autrement être vulnérables. Si vous regardez l'illustration 2 ci-dessus, vous noterez que le code malicieux a été enregistré comme des données dans la pile. Le système exec-shield fonctionne, en partie, en créant une pile (et d'autres zones de mémoire où sont stockées les données) incapable d'exécuter du code. Lorsque le programme est chargé en mémoire pour son exécution, le code et les données sont chargés dans des zones différentes de la mémoire. Il n'y a normalement aucune raison pour que les zones de données aient besoin d'exécuter du code. La rustine exec-shield interdit donc cela. Elle n'interdira pas un débordement de mémoire d'avoir lieu dans un logiciel y étant vulnérable. Mais elle empêchera le pirate d'être capable d'exploiter la vulnérabilité en exécutant un code malicieux stocké dans la pile ou dans les tampons de données.

Installer la rustine n'est pas difficile. Nous allons faire la procédure pas à pas :

Une fois le noyau installé, vous êtes prêt pour redémarrer votre PC afin de le charger. Alternativement, vous pouvez continuer afin de remplacer les paquets ayant une version fonctionnant avec exec-shield.

Certaines des protections offertes par la rustine du noyau exec-shield ne requièrent que d'installer la rustine et de recompiler le noyau. Ceci dit, pour obtenir l'entier bénéfice de exec-shield, vous aurez à exécuter des binaires ayant été compilés avec lui.

La raison de ceci est une conséquence de ce qui est expliqué ci-dessus. La rustine du noyau exec-shield empêchera un intrus d'être en mesure d'exécuter un code malicieux inséré durant l'attaque. Ceci en interdisant la mémoire stockant les données de pouvoir exécuter du code. Cependant, il ne peut arrêter le débordement de mémoire de se produire en premier lieu si un quelconque logiciel a cette vulnérabilité. Si vous vous référez à l'illustration 1, vous verrez que l'adresse mémoire de retour de tout sous-programmes est localisée dans la pile. Un attaquant pourrait éventuellement utiliser l'attaque pour remplacer l'adresse de retour par une adresse allant quelque part ailleurs. Par exemple, la fonction system de la glibc. Si vous avez l'aide en ligne d'installée (man) sur votre PC Slackware, tapez - man system. Vous verrez que cette fonction peut être utilisée par un attaquant afin d'exécuter n'importe quelle commande shell sur votre PC. Ne vous rongez pas les ongles, l'exec-shield protège aussi contre cela, mais d'une manière légèrement différente.

Enfin pour qu'un attaquant malveillant arrive à réécrire l'adresse de retour, il doit connaître l'adresse mémoire exacte sur votre système de la fonction utile. Sans exec-shield d'installé, l'adresse de la fonction system() sur votre système pourrait être la même que sur des centaines d'autres PC sous Slackware. Simplement car ce que Slackware installe sur différents systèmes peut être virtuellement identique. Avec exec-shield, cependant, le noyau rends aléatoire l'emplacement mémoire où sont chargées les bibliothèques partagées. De même il rend aléatoire les adresses mémoire de la pile et des données supplémentaires de chaque programme. Par contre il ne peut rendre aléatoire l'adresse mémoire où est chargé un programme. Ceci parce que l'adresse de chargement d'un programme est déterminé quand il est compilé.

Afin de rendre la position en mémoire où un programme est chargé aléatoire, il doit être compilé en tant que "exécutable à la position indépendante", ou PIE (position-independant executable). Si vous êtes familié des bibliothèques partagées, ceci ressemblera infiniment à "code à position indépendante" (ou PIC) que les bibliothèques partagées utilisent. Ceci parce que ce sont des concepts très proche. Un exécutable à position indépendante est chargé par le noyau de la même manière que les bibliothèques partagées.

Vous n'avez pas besoin de remplacer chaque binaire de votre système par un exécutable PIE. Rappellez-vous, le but ici est de se protéger des attaques par débordement de mémoire à distance. Les programmes qui ne communiquent pas avec l'Internet ne sont pas vulnérables à une attaque à distance et n'ont pas besoin d'une protection supplémentaire. Cet auteur a préparé un jeu de paquets pour la Slackware 10.1 pour les logiciels serveurs qui sont en règle générale le plus souvent audités et attaqués.

Les paquets, disponibles depuis linuxpackages.net, sont : apache, sendmail, bind, imapd, popa3d, portmap, et proftpd. Pour les utiliser, téléchargez simplement les paquets et utilisez upgradepkg en tant que root pour mettre à jour votre paquet courant avec le nouveau :

    # upgradepkg apache-1.3.33-i486-2Hkf.tgz

etc...

Pour les paquets de logiciels tournants actuellement, il est suggéré en premier lieu d'arrêter le logiciel en utilisant le script d'initialisation/démarrage dans /etc/rc.d :

    # /etc/rc.d/rc.bind stop
    # /etc/rc.d/rc.httpd stop
    # /etc/rc.d/rc.portmap stop
    # /etc/rc.d/rc.sendmail stop

Ok, il y a une légère précision à apporter ici sur le sujet nous concernant. Quand, plutôt, il a été dit que exec-shield rendrait la pile et les zones de données inexécutables, c'était seulement en partie vrai. Il le fera, mais il y a certaines très rares façons d'écrire un programme qui requièrent que la pile et les zones de données n'aient pas cette restriction. Chaque fois que GCC détecte un programme écrit ainsi, il pose un drapeau à la fin du programme spécifiant que le système doit avoir une pile exécutable. Si GCC ne détecte pas un programme écrit ainsi, il pose un drapeau disant que tout est en ordre pour que ce programme n'ait pas de pile exécutable. La rustine exec-shield est intelligente, elle regardera ces drapeaux afin de les respecter. Pour les programmes compilés avec une version précédente de GCC ne supportant pas ce drapeau, exec-shield joue la sécurité. Il traite le programme comme s'il avait besoin d'une pile exécutable et désactivera la protection pour ce programme.

Tous les paquets inclus dans la Slackware 10.1 sont compilés avec une version de GCC suffisamment récente pour supporter le drapeau. De plus selon les connaissances de l'auteur il n'y a aucun programmes inclus dans la Slackware 10.1 requièrant une pile exécutable. Cependant, il est possible que vous exécutiez des programmes ayant besoin d'une pile exécutable ou de vieux binaires qui n'ont pas le drapeau. Vous voudrez alors une méthode pour vérifier les programmes tournant sur votre système pour voir si exec-shield est efficace sur eux ou pas. Vous voudrez aussi être capable de vérifier quels programmes sont des exécutables à position indépendante. Un script, appelé lsexec vous permettra de vérifier un ou tous les processus tournant sur votre système. Ce script vous donnera des informations sur tous les processus ou pour un seul processus avec son nom ou son PID (Process IDentifiant). Par exemple, pour avoir des informations sur tous les processus tournants, téléchargez le script, et en tant que root taper :

    # lsexec -all

Pour chaque processus tournant, vous obtiendrez si l'exécutable est PIE, ou si exec-shield est valable ou pas pour lui. Souvenez-vous, exec-shield est actif si le processus n'a pas besoin d'une pile exécutable. Il est inactif si le processus en a besoin ou si l'exécutable a été produit avec une version de GCC ne supportant pas le drapeau.

Il vous sera aussi fournit des informations disant si le processus est relro, partialement relro ou pas relro. Ceci n'est pas couvert ici. Dans le cadre de cet article, il est suffisant de dire que fabriquer un exécutable relro est lié au fait de fabriquer un PIE et cela aide à le rendre plus sûr. Il y a quelques lectures à la fin de cet article pour ceux qui souhaitent obtenir plus d'informations sur les détails techniques.

Il y a quelques informations à se rappeler au sujet de exec-shield. Il peut considérablement augmenter la sécurité de votre système, mais il n'est pas le tout-en-un de la protection. Premièrement il ne peut pas rendre un programme invulnérable à une attaque par débordement de mémoire - pas si le programme a de telles failles en lui. Ce qu'il peut faire c'est atténuer les conséquences de telles failles. Sur une échelle de valeur, il rend plus dur la tâche d'un attaquant pour tirer avantageusement parti de telles failles pour prendre le contrôle de votre système. Cependant un attaquant peut probablement utiliser cette faille pour une attaque de type dénie de service (DOS). Un attaquant peut peut-être causer l'arrêt brutal du programme. Mais il est improbable qu'il puisse utiliser la faille pour obtenir quelques contrôles que se soit sur votre serveur.

De plus rappelez-vous, que l'attaque par débordement de mémoire est seulement un type d'attaque. Utiliser exec-shield ne vous protégera pas contre les autres types d'attaques. Il est toujours important de surveiller les alertes de sécurité et de mettre à jour tous les programmes qui ont été annoncés comme ayant une quelconque faille (faille de débordement de mémoire incluse).

Tout a été dit, exec-shield peut rendre votre système Slackware, serveur ou pare-feu, bien plus sûr.

	Note
	NDT : Il semble que la partie de la rustine allouant aléatoirerement l'adresse mémoire est incorporée dans le noyau à partir de la version 2.6.6. La rustine reste cependant utile afin de rendre la pile et les zones mémoires inexécutables.

Van de Ven, Arien (2004). Nouveaux perfectionnements de sécurité pour la Red Hat Linux Entreprise version 3, mise à jour n°3 [en ligne]. Retrouvé sur l'Internet le 4 Mars 2005 : http://people.redhat.com/mingo/exec-shield/docs/WHP0006US_Execshield.pdf

Drepper, Ulrich (2004). Perfectionnements de sécurité pour la Red HAT Linux Entreprise (près de SELinux) [en ligne]. Retrouvé sur l'Internet le 4 Mars 2005 : http://people.redhat.com/drepper/nonselsec.pdf

Molnar, Ingo (2003). [Annonce] “Exec Shield”, Nouvelle fonctionnalité de sécurité sous Linux [En ligne]. Retrouvé sur l'Internet le 5 Mars 2005 : http://groups.google.ca/groups?q=exec-shield&hl=en&lr=&selm=20030502164023$0fbc@gated-at.bofh.it&rnum=2 (ed. l'archive de l'original de l'annonce d'exec-shield contient des informations en inadéquation avec la version la version courante d'exec-shield)