dwndoc

User Tools

Site Tools

Trace: • testing_for_stack_overflow
hack:testing_for_stack_overflow

Table of Contents

testing_guide

Résumé

Cette section présente un test de débordement qui se concentre sur la façon de manipuler la pile du programme.

Description

Les débordements de pile se produisent lorsque les données de taille variable sont copié dans un buffer de taille fixe situés sur la pile du programme sans aucune vérification des limites. Les vulnérabilités de ce type sont généralement considérées comme de gravité élevée car leur exploitation permet l'exécution de code arbitraire ou un déni de service. Rarement trouvés dans les plates-formes utilisant un langage interprété, le code écrit en C et les langages similaires ont plus souvent ce genre de vulnérabilité.

Presque chaque plate-forme peuvent souffrir de problèmes de débordement de pile, avec les exceptions notables suivantes:

  • J2EE - aussi longtemps que les méthodes natives ou les appels système ne sont pas invoqués
  • .NET - tant que du code « non managé » ou dangereux n'est pas appelé (comme l'utilisation de P/Invoke ou COM Interop)
  • PHP - aussi longtemps que des programmes externes et les extensions PHP vulnérables écrites en C ou C + + ne sont pas appelées

Les vulnérabilités de débordement de pile permettent souvent à un attaquant de prendre le contrôle directement sur le pointeur d'instruction et, par conséquent, de modifier l'exécution du programme et d'exécuter du code arbitraire. En plus d'écraser le pointeur d'instruction, des résultats similaires peuvent également être obtenus en écrasant les autres variables et structures, à l'instar de gestionnaires d'exceptions, qui sont situés sur la pile.

Test boîte noire

La clé de test pour détecter les vulnérabilités de débordement de pile est la fourniture de données d'entrée trop importantes par rapport à ce qui est attendu. Toutefois, en soumettre des données arbitrairement grandes à l'application ne suffit pas. Il est nécessaire d'inspecter le flux d'exécution de l'application et les réponses pour déterminer si un débordement a effectivement été déclenché ou non. Par conséquent, les mesures nécessaires pour localiser et valider le débordement de pile serait d'attacher un débogueur à l'application cible ou d'un processus, générer des données malformées, soumettre ces données à l'application, et inspecter les réponses dans le débogueur. Le débogueur permet au testeur de voir le flux d'exécution et l'état des registres lorsque la vulnérabilité est déclenchée.

D'autre part, une forme plus passive du test peut être utilisée, ce qui implique l'inspection du code assembleur de l'application en utilisant un désassembleur. Dans ce cas, les différentes sections sont scannées pour détecter les signatures des fragments vulnérables. Ceci est souvent appelé « reverse engineering » et est un processus fastidieux.

Un exemple simple, considérons l'emploi de la technique suivante, tout en testant un exécutable “sample.exe” pour provoquer un débordement de pile: 

#include<stdio.h>
int main(int argc, char *argv[])
{
 char buff[20];
 printf("copying into buffer");   
 strcpy(buff,argv[1]);
 return 0;
}

Le fichier sample.exe est lancé dans un débogueur, dans notre cas OllyDbg.

Comme l'application attend des arguments de la ligne de commande, une séquence importante de caractères tels que «A», peut être fournie dans « Arguments » comme ci-dessus.

En ouvrant le fichier exécutable avec les arguments fournis et poursuivre l'exécution les résultats suivants ont été obtenus.

Comme indiqué dans la fenêtre du débogueur , le registre EIP ou Extended Instruction Pointer, qui pointe vers la prochaine instruction à exécuter, contient la valeur '41414141 '. '41 'Est une représentation hexadécimale pour le caractère' A 'et par conséquent, la chaîne «AAAA» se traduit en 41414141.

Cela démontre clairement la façon dont les données d'entrée peuvent être utilisé pour remplacer le pointeur d'instruction avec des valeurs fournies par l'utilisateur et l'exécution du programme de contrôle. Un débordement de pile peut également permettre l'écrasement de structures basées sur des piles comme SEH (Structured Exception Handler) pour contrôler l'exécution de code et contourner certains mécanismes de protection de pile.

Comme mentionné précédemment, d'autres méthodes de tests de telles vulnérabilités comprennent l'ingénierie inverse des binaires de l'application, qui est un processus complexe et fastidieux, en utilisant des techniques de fuzzing.

Test boîte grise

Lors de l'examen des débordements de pile, il est conseillé de rechercher des appels à des fonctions de bibliothèque non sécurisés comme fgets(), strcpy(), strcat() etc qui ne valident pas la longueur des chaînes source et copient aveuglément les données dans des tampons de taille fixe.

Par exemple, considérons la fonction suivante: - 

void log_create(int severity, char *inpt) {
char b[1024];
if (severity == 1)
{
strcat(b,”Error occurred on”);
strcat(b,":");
strcat(b,inpt); 
FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);
. . . . . .
}

La ligne de strcat (b, inpt) donnera lieu à un débordement de pile si inpt dépasse 1024 octets. Non seulement cela démontre une utilisation non sécurisée de strcat, mais aussi combien il est important d'examiner la longueur des chaînes référencées par un pointeur de caractère qui sont passées comme argument à une fonction; Dans ce cas, la longueur de la chaîne référencée par « char *inpt ». Par conséquent, il est toujours recommandé de retracer la source des arguments de la fonction et de vérifier les longueurs de chaîne lors de l'examen du code.

L'utilisation de la fonction strncpy() relativement plus sûre peut aussi conduire à des débordements de pile car elle limite seulement le nombre d'octets copiés dans la mémoire tampon de destination. Si l'argument de taille qui est utilisé pour accomplir ceci est généré dynamiquement en fonction de l'entrée utilisateur ou calculée inexactement dans des boucles, il est possible de provoquer un dépassement de pile des tampons. Par exemple: - 

void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size) 
}

où « source » est une donnée contrôlable par l'utilisateur. Un bon exemple est la vulnérabilité de débordement de pile samba trans2open (http://www.securityfocus.com/archive/1/317615).

Les vulnérabilités peuvent également apparaître dans l'URL et adresser le code. Dans de tels cas, une fonction comme memccpy() est habituellement utilisée pour permettre de copier des données dans une mémoire tampon de destination jusqu'à ce qu'un caractère spécifié ne soit rencontré. Considérons la fonction: 

void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}

Dans ce cas, les informations contenues dans le chemin pourraient être supérieure à 40 octets avant qu'on ne rencontre '\'. Si c'est le cas cela va provoquer un débordement de pile. Une vulnérabilité similaire a été localisé dans les sous-système Windows RPCSS (MS03-026). Le code vulnérable copie les noms des serveurs des paths UNC dans un tampon de taille fixe jusqu'à ce qu'un '\' ait été rencontré. La longueur du nom de serveur dans ce cas était contrôlable par les utilisateurs.

En dehors de l'examen manuel de code pour détecter le débordement de pile, des outils d'analyse statique de code peuvent aussi être d'une grande aide. Bien qu'ils aient tendance à générer beaucoup de faux positifs et ne sont capables de détecter qu'une petite partie des défauts, ils peuvent certainement aider à réduire la surcharge de travail associée à la découvertes de bugs, comme strcpy() et sprintf(). Une variété d'outils comme des RATS, flawfinder et ITS4 sont disponibles pour l'analyse des langages de style C..

Références

Livres Blancs

Outils

hack/testing_for_stack_overflow.txt · Last modified: 2019/02/13 13:10 by 127.0.0.1