Dans ce test, nous vérifions si un testeur peut faire un débordement de heap(tas) qui exploite un segment de mémoire.

Un Heap est un segment de mémoire utilisé pour stocker les données allouées dynamiquement et les variables globales. Chaque bloc de mémoire dans le heap se compose de balises de délimitation qui contiennent des informations de gestion de la mémoire.

Quand un tampon heap-based est débordé, les informations de contrôle dans ces balises sont écrasées. Lorsque la routine de gestion des heap libère la mémoire tampon, une écrasement de la mémoire adressée a lieu conduisant à une violation d'accès. Lorsque le trop-plein est réalisé de façon contrôlée, la vulnérabilité permettrait à un adversaire d'écraser un emplacement de mémoire souhaité avec une valeur commandée par l'utilisateur. Dans la pratique, l'attaquant devrait être en mesure de remplacer les pointeurs de fonction et les adresses stockées dans diverses structures telles GOT,. Dtors ou TEB avec l'adresse d'une charge utile malveillante.

Il existe de nombreuses variantes du débordement de heap (heap corruption) la vulnérabilité qui peut permettre d'écraser les pointeurs de fonction pour exploiter les structures de gestion de mémoire pour l'exécution de code arbitraire. La détection des débordements de heap nécessite un examen plus approfondi que les débordements de pile, car il ya certaines conditions qui doivent exister dans le code pour pouvoir exploiter cette vulnérabilité.

Les principes de tests de boîte noire pour les débordements de heap restent les mêmes que pour les débordements de pile. La clé est de fournir des chaînes d'entrée plus longues que prévues. Bien que le processus de test reste le même, les résultats visibles sont significativement différentes. Alors que dans le cas d'un débordement de la pile, un pointeur d'instruction ou SEH écrasé serait évident, ce n'est pas le cas pour une débordement de heap. Lorsque vous déboguez un programme Windows, un débordement de heap peut apparaître sous différentes formes, la plus courante étant un échange de pointeur ayant lieu après la routine de gestion des heaps entre les actions. Le scénario ci-dessous illustre une vulnérabilité de type débordement de tas.

Les deux registres indiqués, EAX, ECX peuvent être rempli des adresses fournies par l'utilisateur et qui font partie des données qui sont utilisées pour un dépassement de mémoire tampon. L'une des adresses peut pointer vers un pointeur de fonction qui doit être remplacé, par exemple UEF (filtre d'exception non gérée), et l'autre peut être l'adresse d'un code fourni par l'utilisateur qui doit être exécuté.

Lorsque les instructions MOV figurant dans le volet de gauche sont exécutés, l'écrasement a lieu et, lorsque la fonction est appelée, le code utilisateur fourni est exécuté. Comme mentionné précédemment, d'autres méthodes de tests de telles vulnérabilités comprennent l'ingénierie inverse des binaires d'application, qui est un processus complexe et fastidieux, et utilisent des techniques de fuzzing.

Lors de l'examen du code, il faut savoir qu'il y a plusieurs endroits où des vulnérabilités de ce type peuvent survenir. Le code qui semble anodin au premier abord, peut effectivement être vulnérable sous certaines conditions. Comme il existe plusieurs variantes de cette vulnérabilité, nous allons couvrir uniquement les failles prédominantes. La plupart du temps, les tampons des heaps sont considérés comme sûrs par beaucoup de développeurs qui n'hésitent pas à effectuer des opérations non sécurisé telles que strcpy(). Le mythe selon lequel un débordement de pile et l'écrasement du pointeur d'instruction sont les seuls moyens d'exécuter du code arbitraire se révèle être dangereux en cas de code ci-dessous:

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

               vulnerable(argv[1]);                                             
               return 0;
       }

       int vulnerable(char *buf)
       {

               HANDLE hp = HeapCreate(0, 0, 0);                

               HLOCAL chunk = HeapAlloc(hp, 0, 260);

               strcpy(chunk, buf);  ** Vulnerability** 

                         …….. 

               return 0;
       }

Dans ce cas, si buf est supérieur à 260 octets, il va écraser les pointeurs dans la balise adjacente, facilitant l'écrasement d'un emplacement mémoire arbitraire avec 4 octets de données une fois la routine de gestion de heap entre en jeu.

Dernièrement, plusieurs produits, en particulier des bibliothèques anti-virales, ont été touchés par des variantes qui sont des combinaisons d'un débordement d'entier et la copie dans la mémoire tampon. A titre d'exemple, considérons un extrait de code vulnérable, une partie du code responsable du traitement des types de fichiers TNEF, de Clam Anti-Virus 0.86.1, le fichier source tnef.c et la fonction tnef_message():

string = cli_malloc(length + 1); ** Vulnerability**
if(fread(string, 1, length, fp) != length) {** Vulnerability**
free(string);
return -1;
}

La fonction malloc à la ligne 1 alloue de la mémoire basée sur la valeur de length, qui se trouve être un entier de 32 bits. Dans cet exemple particulier, la longueur est contrôlable par l'utilisateur et un fichier TNEF malveillant peut être conçu pour régler la longueur à '-1', ce qui se traduirait par malloc(0). Par conséquent, cette malloc allouera un petit heap buffer, qui serait de 16 octets sur la plupart des plates-formes 32 bits (comme indiqué dans malloc.h).

Et maintenant, à la ligne 2, un débordement de tas se produit dans l'appel à la fonction fread ). Le 3ème argument, dans ce cas, length, devrait être une variable size_t. Mais si c'est '-1', l'argument est renvoyé avec0xFFFFFFFF, donc la copie de 0xFFFFFFFF octets dans la mémoire tampon de 16 octets.

Des outils d'analyse statique de code peuvent aussi aider à détecter les vulnérabilités tas connexes tels que “double free”, etc Une variété d'outils comme des RATS, flawfinder et ITS4 sont disponibles pour l'analyse des langages de style C..

• w00w00: “Heap Overflow Tutorial” - http://www.cgsecurity.org/exploit/heaptut.txt * David Litchfield: “Windows Heap Overflows” - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt ## Outils ## * OllyDbg: “Un débogueur utilisé pour l'analyse des vulnérabilités de type buffer overflow” - http://www.ollydbg.de * Spike: un framework fuzzer qui peut être utilisé pour explorer les vulnérabilités et effectuer des tests de longueur - http://www.immunitysec.com/downloads/SPIKE2.9.tgz * Brute Force Binary Tester (BFB): un correcteur binaire proactive - http://bfbtester.sourceforge.net