[Mécanisme de sécurité Microsoft Windows XP/VISTA – Partie 3] SafeSEH

Par Rédaction, secuobs.com
Le 18/12/2007

---

Résumé : Sous Windows, les exceptions sont gérées par les Structured Exception Handling suite à une erreur logicielle. Les SEH pouvant être facilement modifiables, le développement d’une nouvelle génération de SEH avec SafeSEH a été entrepris. - Lire l'article



Sous Windows, les exceptions sont gérées par ce que l'on appelle les Structured Exception Handling ou SEH ; une exception est exécutée en cas d’erreur au niveau logiciel comme un accès à une adresse mémoire invalide ou une division par zéro, elles sont très couramment utilisées dans le domaine des protections logicielles. Le principe des SEH fonctionne par des séries de pointeurs, on récupère son adresse grâce au TIB (Thread Information Block), situé a une adresse fixe définie par le segment FS.

La liste des exceptions possibles est disponible dans les manuels INTEL ( lien ), les plus courantes sont la division par zéro (ce qui est mathématiquement impossible) et l’accès à une adresse mémoire invalide, en effet si une adresse n’existe pas on ne peut pas logiquement y accéder.

typedef struct _NT_TIB32 {
unsigned long ExceptionList;
unsigned long StackBase;
unsigned long StackLimit;
unsigned long SubSystemTib;
unsigned long FiberData;
unsigned long Version;
unsigned long ArbitraryUserPointer;
unsigned long Self;
};


Le dword nous intéressant est celui de l’ExceptionList, les autres arguments portant un nom explicite ne nous intéresse pas pour la démonstration. Ensuite on copie un pointeur vers EXCEPTION_REGISTRATION_RECORD que l’on va stocker dans ExceptionList, qui est le premier dword du TIB ; usuellement cette structure est stockée dans la pile mémoire :

typedef struct _EXCEPTION_REGISTRATION_RECORD {
struct _EXCEPTION_REGISTRATION_RECORD * Next;
function * Handler;
};


Voici une simulation de l’action en assembleur :


Lea eax, ExceptionList
Mov [eax+4], 0DEADBABEh // On écrase le Handler par 0xDEADBABE
Mov fs :[0], eax


Si l’on récrit le champ Handler vers un pointeur sur notre code malveillant, il ne nous reste plus alors qu’à générer une exécution pour que ce shellcode soit exécuté ; voilà grossièrement comment une SEH est mise en place, un Handler de SEH est tout simplement un pointeur vers une fonction qui sera appelé dès qu’une exception apparaîtra. Les code malveillant en question aussi appelé shellcode sont disponible librement sur des sites tels que celui du Metasploit Project ( lien ).


push offset Handler ; Initialise l’handler.
push dword ptr fs:[0] ; Initialise l’handler.
mov dword ptr fs:[0], esp ; Insère le handler dans la liste chaînée SEH

[…] Ici une exception doit être générée pour exécuter le handler.

pop dword ptr fs:[0] ; Restaure le handler.
add esp, 4 ; Restaure l'état de la pile mémoire


Le principe, de l’exécution par les SEH, est d’écraser le handler sur la pile mémoire, vers notre buffer par exemple, puis de générer une exception.Voici un exemple montrant un programme, avec code source détaillé, qui s’exploite tout seul, afin de voir clairement les étapes exécuter lors d’un buffer overflow. Que l’attaque soit locale ou distante, les étapes restent les mêmes :

void hook(void)
{
printf("Exemple SEH !!!\n");
}

int main(int argc, char **argv)
{
unsigned long stack;

//
// mise en place de SEH.
//

//
// Comme expliqué plus haut on definit ici le handler du SEH dans le TIB.
//
_asm {
push offset Handler
push dword ptr fs:[0]
mov fs:[0], esp
mov stack, esp
}

printf("Handler: %08X\n", *(long *)(stack+4));
printf("Remplacer le handler courrant...\n");

//
// Ici l’on modifie directement l’handler qui se situe sur la stack.
//

*(long *)(stack+4) = (long)&hook;
printf("Handler: %08X\n", *(long *)(stack+4));

_asm {

//
// On génère l'exception
//

xor eax, eax
mov [eax], eax // On essaye d’écrire en position 0x00000000, ce qui n’existe pas
// On a donc une exception générée.

pop dword ptr fs:[0]
add esp, 4

Handler:
}

printf("Bye Bye!\n");
return 0;
}


L'exécution donne le résultat suivant :

\Projects\seh\release>seh.exe
Handler: 004017BA
Replace the current handler...
Handler: 00401730
Exemple SEH !!!


Le fait que les SEH pouvaient être facilement modifiables, a entraîné le développement d’une nouvelle génération de SEH avec SafeSEH. Le handler est alors appelé uniquement s’il n’appartient pas à la pile ; même si on peut réaliser un « stack overflow » et y placer un shellcode on ne pourra pas le faire s'exécuter. De plus ample information sur le SafeSEH sont disponible sur le site de la MSDN ( lien )

L’exploitation dépend donc de la faille. Si la faille est exploitable à cause d’une source extérieure comme un fichier. Le programme est obligé de lire le fichier, et donc le code malveillant disposera d’une adresse par laquelle il devra remplacer le handler original ! Ainsi, on aura un code malveillant situé à une adresse donnée mais pas forcément sur la stack.

Imaginons que la cible qui est un lecteur mp3 lise le fichier directement via un mapping avec le paramètre EXECUTE, cela signifie que le code mappé en mémoire est directement exécutable

FObject->FileMap = CreateFileMapping(FObject->File,
0,
PAGE_EXECUTE_READWRITE,
0,
0,
0);


Surtout il ne faut jamais donner tous les droits à une page mappée, juste les droits les plus essentiels, un PAGE_READONLY aurait dans ce cas fait largement l’affaire. Mais rien ne dit que le code ne sera pas copié vers un Heap dans la suite des événements. Pour rappel uniquement les pointeurs vers la Stack ne peuvent pas être exécutés, ce qui veut dire que les pointeurs vers le Heap sont autorisés à l'exécution.Le principe des heap overflow est sensiblement le même que celui des stack overflow à l'exception qu’il est nécessaire d'exécuter un malloc/HeapAlloc pour générer le buffer :

HANDLE h = HeapCreate(0, 0, 0); // default flags

DWORD vulner(LPVOID str)
{
LPVOID mem = HeapAlloc(h, 0, 128);
// [..]
strcpy(mem, str);
// [..]
return 0;
}


On a un buffer de type heap, puis un appel à strcpy() copiant un argument vers le buffer sans contrôle de la taille donc un buffer overflow potentiel.La recette d’un buffer overflow est simple, il suffit de deux choses : un buffer et un contrôle de la taille insuffisant.

En 2005, MaxPatrol annonce que l'exécution d'un heap overflow qui soit disant devaient être impossible à réaliser avec le Service Pack 2 (SP2) de Microsoft Windows XP, est en fait tout à fait possible ( lien ). De plus, la société MaxPatrol a même publié des exemples montrant comment exploiter un heap overflow sous Windows XP SP2. A la surprise générale, l’exploitation s’avèra assez simple mais nécessite des conditions particulières réduisant les cas possibles d’exploitation dans le monde « réel ».

En effet, MaxPatrol montre un exemple dans lequel deux buffers de taille X et Y sont alloués puis libérés, de nouveau un buffer de taille X est créé puis écraser, ce qui génère la réécriture des pointeurs qui définissent les Heap lors de l’allocation d’un nouveau buffer de taille Y. Des exemples détaillés sont disponible sur le site de MaxPatrol.


Autres ressources dans ce dossier :

[Mécanisme de sécurité Microsoft Windows XP/VISTA – Partie 1] Présentation des problématiques – lien

[Mécanisme de sécurité Microsoft Windows XP/VISTA – Partie 2] /GS et cookie – lien

[Mécanisme de sécurité Microsoft Windows XP/VISTA – Partie 4] Address Space Layout Randomization, No eXecution et User Account Control – lien

[Mécanisme de sécurité Microsoft Windows XP/VISTA – Partie 5] Patchguard, rootkit, hibernation et webographie – lien