SecureM

Attention, aujourd'hui je vous présente un type d'attaque très particulier, et très complexe : les Buffers Overflows !

Il s'agit de l'exploitation d'une faille dite "applicative", c'est-à-dire que la faille concerne des applications, des programmes qui sont exécutés par votre ordinateur (votre navigateur en est un, mais des tas de services systèmes sont aussi des programmes). C'est une faille malheureusement encore trop répandue, et qui permet très souvent de faire exécuter du code arbitraire par le programme vulnérable (de commander le programme en question). C'est aussi une faille très très complexe, qui nécessite une solide connaissance du fonctionnement interne du système, mais j'essaierai de décrire simplement les parties qui nous intéressent.

Le principe

Pas besoin d'être bilingue anglais pour comprendre l'idée (d'accord, faut savoir ce qu'est un buffer) : littéralement "dépassement de tampon", il s'agit de faire rentrer dans un "buffer" (une zone de stockage temporaire) plus de données que prévu, et de le faire déborder pour injecter des données ailleurs dans la mémoire. Si, si. Et c'est vachement efficace (quand ça marche).

Les prérequis : la structure de la mémoire

Un processeur utilise ce qu'on appelle des registres, qui ont pour rôle de stocker diverses informations relatives à l'exécution des programmes. Nous nous intéresserons ici surtout au registre EIP (Extended Instruction Pointer), qui est sans doute le plus important puisqu'il stocke l'adresse de l'instruction en cours d'exécution (un programme étant constitué d'instructions).

Lorsqu'un programme est lancé, le système réserve une zone de mémoire pour son exécution, dans lequel sont stockés 5 segments :

Le code vulnérable

Et voici maintenant le code source qui va nous permettre d'obtenir un programme vulnérable aux Buffers Overflows (écrit en C, c'est par ici si vous ne connaissez rien au C - attention c'est très long d'apprendre à coder) :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void enregistrer_nom(char *nom_saisi) {

   char buffer_nom[100];

   strcpy(buffer_nom,nom_saisi);

   printf("Votre nom, %s, a été enregistré avec succès\n",buffer_nom);

}

int main(int argc, char *argv[]) {

   if (argc != 2) {
     printf("Usage : %s < Votre nom >\n",argv[0]);
     exit(0);
   }

   enregistrer_nom(argv[1]);

   printf("Fin du programme...\n");
   return 0;
}

   char buffer_nom[100];
   strcpy(buffer_nom,nom_saisi);

On a le droit à une jolie erreur de segmentation ! (et vous avez remarqué que le message "Fin du programme..." ne s'est donc pas affiché)

La réécriture de la pile

Souvenez-vous de la constitution du segment STACK, on a dans l'ordre : les arguments, le Return Address (adresse de retour qui sera prise par l'EIP à la fin de la fonction), puis d'autres trucs moins intéressants, puis les variables locales, donc ici le buffer_nom qui reçoit la valeur du nom de l'utilisateur.

L'image de gauche montre la structure de la pile. Le haut de la pile correspond aux adresses les plus basses, et le bas aux plus hautes. Les données sont copiées dans en partant des adresses les plus basses vers les plus hautes (donc de haut en bas sur l'image et dans la pile).

A droite, voici la pile après copie du nom dans le buffer_nom : le processeur a copié dans la partie variables locales (buffer_nom est une variable locale, définie à l'intérieur de la fonction) ce qu'on lui a demandé, c'est-à-dire le nom récupéré. Mais comme il ne sait pas que le buffer ne fait que 100 caractères (en fait, c'est la fonction strcpy qui ne fait pas de vérification), il va continuer de copier jusqu'à la fin du nom, et va donc déborder (vers le bas puisque les données sont copiées de haut en bas) dans d'autres cases mémoires... dont le RA (Return Address) qui contient l'adresse de la prochaine instruction après la fin de la fonction. Et justement, à la fin de la fonction, EIP va prendre la valeur de RA qui ne correspond sûrement pas à une instruction valide... bim. Erreur de segmentation.

Et si on observe le crash du programme à travers le logiciel GDB (qui permet d'analyser finement les plantages), on observe :

On voit que le processeur est allé à l'adresse 0x0000414141414141 et n'y a pas trouvé d'instruction valide... Et vous savez quoi ? Le caractère "A", en hexadécimal, s'écrit 0x41. On a donc réussi à placer des "A" dans le RA, et à détourner ce qu'on appelle le "flux d'exécution" du programme !
(bon, ok, là on l'a détourné mais il est pas allé loin...)

Utilisation basique d'un buffer overflow :

Vous l'aurez sûrement compris, le principe d'un Buffer Overflow est de réécrire l'adresse de retour ! Mais pour le détourner vers où ?

Pour notre exemple on va simplement le rediriger vers une autre fonction du programme !

Allez, un autre exemple bidon :

#include <stdio.h>
#include <stdlib.h>

#include <string.h>

// On définit le mot de passe secret qui déverrouillera l'accès
#define PASSE_SECRET "o$12kIjaZ"

// Déverrouillage de l'accès à l'entrepôt d'armes
void deverrouillage(){
    printf("Bienvenue M. Chef !\n\n");
    printf("Déverrouillage de la porte... ");
    /* Oui bon... je vais pas faire une fonction

	pour ouvrir une porte non plus ! */
    
    printf(" porte déverrouillée !\n\n");
}

// Vérification du mot de passe
void verifier_passe(char *passe_saisi) {

    char buffer_nom[100];

    strcpy(buffer_nom,passe_saisi);
    
    if(strcmp(passe_saisi,PASSE_SECRET) == 0) // Si le passe est correct

      deverrouillage(); // On déverrouille
    else
      printf("Mauvais mot de passe !\n"); // ...ou pas.
}

int main(int argc, char *argv[]) {

    if (argc != 2) {
      printf("Usage : %s < Mot de passe supersecret >\n",argv[0]);
      exit(0);
    }
    
    // Vérification du passe, et déverouillage si le passe est valide

    verifier_passe(argv[1]);

    printf("Fin du programme...\n");
    return 0;
}

Ce programme se contente de demander un mot de passe pour déverrouiller l'entrepôt aux armes de la CIA (ça reste un exemple ^^). Nous, on est 007. Et on connaît pas le mot de passe.

Mais comme on sait que le programmeur n'a pas fait attention, on va utiliser un Buffer Overflow pour ouvrir cette satanée porte !

Bon, allez, on utilise notre super téléphone-à-tout-faire pour lancer le programme dans GDB :

Ah bah tiens, ça alors ! Une fonction de déverrouillage, à l'adresse 0x0000000000400659 ! Mais elle n'est pas appelée à moins d'avoir le mot de passe...

Allez, et si on essayait de placer cette fameuse adresse dans le RA ? Hein ? Comme ça, à la fin de la fonction, cette fonction de déverrouillage serait appelée !

Bon, on a l'adresse  0x004141 et on cherche l'adresse 0x400659. Avec un A en plus ?

Voilà, on a le bon nombre d'octets, on n'a plus qu'à remplacer les 3 derniers A par la valeur en hexadécimal de l'adresse (attention comme, notre système est en little endian, il faut inverser l'ordre des octets).

Et voilà !! (ne vous extasiez pas, c'est normal pour James Bond...)

Quelques remarques : j'ai utilisé une commande Perl pour obtenir les caractères correspondants aux valeurs hexadécimales. Et puis, le programme a aussi planté puisque de toutes manières, on lui avait supprimé des bouts de mémoire (remplacés pour être exact).

Et voilà pour cette première partie !

Prochaines parties :

Pour cet article, nous avons vu comment appeler n'importe quelle fonction de manière arbitraire, à condition que le programme soit vulnérable (présence d'une fonction strcpy par exemple). Mais nous ne pourront jamais faire que ce qui a été écrit dans le programme (James Bond n'aurait pas pu jouer à Pacman parce qu'aucune fonction pour y jouer n'était présente dans le programme), et ça limite très rapidement le champ d'action.

Nous allons donc voir dans la prochaine partie le moyen d'exécuter notre propre code dans le programme, au moyen notamment de ShellCodes à injecter. On s'intéressera aussi au moyen d'exécuter ce code avec des droits plus élevés si le programme répond à quelques conditions :)