www.hakin9.org hakin9 Nº 1/2007 2 Fiche technique L a version 2.6 du noyau Lin
www.hakin9.org hakin9 Nº 1/2007 2 Fiche technique L a version 2.6 du noyau Linux comprend une protection très simple contre l’ex ploitation des vulnérabilités liées au débordement du buffer. Cette protection per met notamment d’empêcher le fonctionnement des anciennes techniques d’exploitation des débordements, techniques toujours largement utilisées de nos jours. Toutefois, cette protec tion ne suffit pas à décourager les pirates les plus déterminés. La version 2.6 du noyau Linux propose une protection contre l’exploitation des débor dements du buffer. Cette protection consiste à rendre aléatoire le début de chaque pro cessus sur la pile. À chaque exécution d’un programme, la pile part d’une adresse pouvant varier dans un intervalle de 8 Mo. Cette protec tion permet ainsi d’empêcher le fonctionnement des techniques d’exploitation traditionnelles qui consistent à trouver le ShellCode toujours à une adresse déterminée. Le ShellCode, géné ralement compris dans une buffer overflow ou une variable d’environnement, se trouve ainsi à une position différente à chaque exécution d’un programme. Le présent article a pour objectif d’expli quer comment contourner simplement cette protection au moyen de deux techniques dif férentes. La première consiste à lancer une attaque en force sur l’adresse du ShellCode permettant d’accéder à un interpréteur de commandes root après quelques essais. La seconde technique, généralement utilisée pour les exploitations du système Windows, consiste à rediriger le flux d’exécution vers un code opération particulier. Comment contourner la protection aléatoire de la pile sur le noyau 2.6 Enrico Feresin Degré de difficulté Aujourd’hui, les spécialistes en informatique ne cessent de découvrir de nouvelles vulnérabilités liées au débordement du buffer, rendant nécessaire le développement de protections capables de maintenir un certain niveau de sécurité sur les systèmes, et ce quelle que soit la présence de vulnérabilités sur un programme installé. Cet article explique… • Comment contourner la protection aléatoire du noyau Linux, version 2.6, afin d’exploiter con crètement la pile grâce aux vulnérabilités liées au débordement du buffer. Ce qu’il faut savoir… • le langage C, • les techniques d’exploitations de la pile. Débordement du buffer sur le noyau 2.6 hakin9 Nº 1/2007 www.hakin9.org 2 Programme vulnérable Le programme vulnérable aux ex ploitations auquel il est fait référence dans les paragraphes suivants a été baptisé vuln1.c, tel qu’exposé dans le Listing 1. Comme vous pouvez le remarquer, un buffer overflow de 32 octets est allouée, et des données y sont copiées sans aucun contrôle préalable de la taille de la mémoire. L’exploitation de cette vulnérabilité permet de faire déborder le buffer, ce qui rend possible l’écrasement de la pile. La Figure 2 illustre la façon de compiler ce programme. Le système utilisé pour les tests est Fedora 4 avec le noyau 2.6.14.4 vanilla. Attaque en force sur l’adresse La première vulnérabilité détectable dans le mécanisme de protection proposé dans la version 2.6 du noyau Linux réside dans l’insuffi sance du caractère aléatoire de l’adresse de départ de la pile. Le champ des adresses possibles dans lesquelles la pile peut être trouvée n’est en réalité large que de 8 Mo. Ainsi, si un nombre élevé d’instruc tions NOP (No Operation) est entré juste avant le ShellCode, il devient alors possible d’augmenter la pro babilité de deviner l’adresse de sorte que seules quelques tentatives d’une attaque en force suffisent à obtenir l’interpréteur de commandes en utili sateur root. Cette méthode reste de toute évidence valable dans le cadre d’une attaque locale. Consultez maintenant le code inti tulé bruteforce-exp.c, exposé dans le Listing 2. Ce code permet d’exploiter la vulnérabilité de débordement du buffer tout en modifiant l’enregistre ment d’activation de la fonction afin de rediriger le flux d’exécution. Le paramètre passé dans le programme vulnérable possède en réalité une longueur de 64 octets. Une fois ce dernier copié dans le buffer overflow de 32 octets, il engendre une modifi cation dans la mémoire adjacente. Inséré dans une variable d’envi ronnement, le ShellCode est précédé par 128 000 instructions NOP. Ainsi, Bibliothèque libShellCode La création d’un ShellCode à utiliser dans le cadre d’une exploitation peut s’avérer dif ficile pour les développeurs ne connaissant pas le langage assembleur. Ceux d’entre vous qui préfèrent ne pas perdre leur temps et souhaitent développer rapidement un exploit peuvent directement utiliser la bibliothèque libShellCode. Comme son nom l’indique, libShellCode est une bibliothèque Open Source. Cette bibliothèque permet de créer des ShellCodes pendant l’exécution. Les interfaces de programmation proposées permettent de créer différentes sortes de ShellCodes pour Linux ainsi que pour BSD. La bibliothèque libshellCode peut s’utiliser de deux manières différentes : elle peut être insérée sous forme de bibliothèque à l’intérieur des exploitations en question ou utilisée via une application frontale afin de faciliter la création de ShellCodes prêts à être lus. Dans le premier cas, les interfaces de programmation de la bibliothèque sont disponibles dans le code de l’exploitation ce qui lui permet d'avoir une meilleure flexibilité. Nous avons exposé dans la Figure 1 l’application frontale utilisée. Vous pouvez télécharger la bibliothèque LibShellCode à partir du l’URL suivante : http://www.orkspace.net/software/libShellCode Figure 1. Application frontale pour la bibliothèque libShellCode Figure 2. Comment compiler le programme vulnérable hakin9 Nº 1/2007 www.hakin9.org Fiche technique 2 les instructions NOP et le ShellCode couvrent à eux deux près de 1/65 (explication de 1/65) de l’étendue de l’adresse de la pile. En cas de problè mes pendant l’exécution du test, il est recommandé de réduire le nombre d’instructions NOP, en veillant à ne pas exagérer : en réalité, plus vous dimi nuer le nombre d’instructions NOP, plus le nombre de tentatives néces saires à une attaque en force réussie augmentera. La valeur utilisée pour modifier l’enregistrement d’activation est cal culée de sorte à maximiser l’effet pa rachute proposé par les instructions NOP. Il vous faut prendre l’adresse de la pile la plus grande possible (0xc0000000) à laquelle vous ôterez la taille de certains éléments se trou vant immédiatement après le début de la pile, ainsi que la taille de la variable d’environnement contenant le ShellCode, directement située après. Dans la Figure 3, la partie colorée représente l’étendue de la mémoire sur 8Mo dans laquelle le sommet de la pile peut être trouvé. La partie rouge représente la zone couverte par l’exploitation alors que la partie jaune représente la zone non cou verte. Si l’adresse du sommet de la pile se trouve à l’intérieur de la partie jaune, le programme échouera en retournant une erreur Segmentation Fault puisque le flux d’exécution sera redirigé vers une zone de la mémoire contenant du code non exécutable. Si le sommet de la pile se trouve dans la partie rouge, le flux d’exécution sera redirigé dans les instructions NOP, ce qui permettra l’exécution du ShellCode. Remarques particulières sur le ShellCode : le code utilisé pour lan cer l’attaque en force sur l’adresse exécute la fonction fork() d’une part au moyen du processus fils, afin d’essayer d’exploiter le programme vulnérable, et d’autre part au moyen du processus père, afin de contrôler le résultat. Si l’exploitation fonc tionne, l’interpréteur de commandes root sera exécuté par le processus fils dépourvu de console en tant que données d’entrée standard. Or, cette Figure 3. Représentation de l’amplitude du caractère aléatoire de la pile Figure 4. Exécution de l’attaque bruteforce-exp.c Figure 5. Structure du buffer overflow utilisée par la seconde exploitation Figure 6. Structure de la pile après l’opération d’écriture Débordement du buffer sur le noyau 2.6 hakin9 Nº 1/2007 www.hakin9.org 23 manœuvre a pour effet d’entraîner l’arrêt immédiat de l’interpréteur de commandes. Afin d’éviter un tel pro blème, le ShellCode doit fermer le descripteur du fichier d’entrée stan dard (correspondant à 0), puis ouvrir le dispositif /dev/tty, lequel permettra de lire les données d’entrée à partir de la console avant d’exécuter l’inter préteur de commandes. La Figure 4 illustre quelques exécutions de l’exploitation. Comme vous pouvez le constater par vous- même, chaque attaque en force fonctionne après un nombre différent de tentatives sans excéder toutefois la dizaine. Redirection vers l’instruction jmp *%esp Il existe également une technique permettant de contourner la protec tion proposée dans le noyau, 2.6, ceci de façon plus élégante que la précédente, même sans connaître l’adresse du ShellCode. La dite technique, initialement utilisée dans le cadre d’exploitations Windows, consiste à écraser l’enre gistrement d’activation au moyen de l’adresse de l’instruction jmp *%esp, déjà présente dans la mémoire du programme vulnérable. Peu importe le segment de la mémoire dans le quel cette instruction se trouve, cette technique suffit à obtenir l’exécution de l’ensemble des attributs. Pour ceux d’entre vous qui ne connaissent pas le langage machine, cette instruction exécute un saut vers Listing 1. Programme vulnérable vuln.c /* * __ ___ _ * / \ | \ | | /\-------------------------------------------------------> * / /\ \| |\ \| |/ / * / /__\ \ /| / * \______/ |\ \| | \ *<--------|_| \_\_|\_\ * * Programme vulnérable à une exploitation par débordement du buffer. * */ uploads/S4/ comment-contourner-la-protection-aleatoire-de-la-pile-sur-le-noyau-2-6-pdf.pdf
Documents similaires
-
27
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Fev 25, 2021
- Catégorie Law / Droit
- Langue French
- Taille du fichier 1.0922MB