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

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

---

Résumé : Le flag /GS, activé par défaut sous Visual Studio 2005, permet de générer un cookie en vue de prévenir l’exécution de code malveillant attaché à l'exploitation d'une faille de type dépassement de mémoire tampon ou Buffer overflow. - Lire l'article



Le flag /GS est activé par défaut sous Visual Studio 2005 ( lien ), il permet de générer un cookie parfois appelé également canarie ; cette option ne permet pas d’empêcher les attaques de type overflow, mais elle permet tout de même de prévenir l’exécution de code malveillant s'y attachant.

On définira le cookie comme un entier témoin, stocké à deux endroits différents afin de pouvoir vérifier son authenticité, c'est-à-dire d’en détecter la moindre modification. Le cookie est stocké dans la pile mémoire au début d’une fonction appelée prologue, puis à la fin de la fonction appelée epilogue la fonction __security_check_cookie vérifie l’authenticité du cookie avant de quitter la fonction avec l'opcode retn si le cookie est bien valide.

Pour information, le cookie est généré par la fonction __security_init_cookie(), qui est exécutée pendant l’initialisation des CRT (C Run-Time Library) c'est-à-dire par la fonction __mainCRTStartup. Cette fonction utilise une série de paramètres aléatoires générés par les fonctions suivantes : le temps avec GetSystemTimeAsFileTime, GetTickCount et QueryPerformanceCounter ainsi que les ID du processus et du thread avec GetCurrentProcessId, GetCurrentThreadId.

Pour les plus curieux d’entre vous voici l’algorithme de génération du cookie :

.text:004016F4 __security_init_cookie proc near; CODE XREF: mainCRTStartupp
.text:004016F4
.text:004016F4 PerformanceCount= LARGE_INTEGER ptr -10h
.text:004016F4 SystemTimeAsFileTime= _FILETIME ptr -8
.text:004016F4
.text:004016F4 push ebp
.text:004016F5 mov ebp, esp
.text:004016F7 sub esp, 10h
.text:004016FA mov eax, __security_cookie
.text:004016FF and [ebp+SystemTimeAsFileTime.dwLowDateTime], 0
.text:00401703 and [ebp+SystemTimeAsFileTime.dwHighDateTime], 0
.text:00401707 push ebx
.text:00401708 push edi
.text:00401709 mov edi, 0BB40E64Eh
.text:0040170E cmp eax, edi
.text:00401710 mov ebx, 0FFFF0000h
.text:00401715 jz short __generate_cookie
.text:00401717 test eax, ebx
.text:00401719 jz short __generate_cookie
.text:0040171B not eax
.text:0040171D mov __security_cookie_complement, eax
.text:00401722 jmp short _exit
.text:00401724 ;
.text:00401724
.text:00401724 __generate_cookie: ; CODE XREF: __security_init_cookie+21j
.text:00401724 ; __security_init_cookie+25j
.text:00401724 push esi
.text:00401725 lea eax, [ebp+SystemTimeAsFileTime]
.text:00401728 push eax ; lpSystemTimeAsFileTime
.text:00401729 call ds:__imp__GetSystemTimeAsFileTime@4 ; GetSystemTimeAsFileTime(x)
.text:0040172F mov esi, [ebp+SystemTimeAsFileTime.dwHighDateTime]
.text:00401732 xor esi, [ebp+SystemTimeAsFileTime.dwLowDateTime]
.text:00401735 call ds:__imp__GetCurrentProcessId@0 ; GetCurrentProcessId()
.text:0040173B xor esi, eax
.text:0040173D call ds:__imp__GetCurrentThreadId@0 ; GetCurrentThreadId()
.text:00401743 xor esi, eax
.text:00401745 call ds:__imp__GetTickCount@0 ; GetTickCount()
.text:0040174B xor esi, eax
.text:0040174D lea eax, [ebp+PerformanceCount]
.text:00401750 push eax ; lpPerformanceCount
.text:00401751 call ds:__imp__QueryPerformanceCounter@4 ; QueryPerformanceCounter(x)
.text:00401757 mov eax, dword ptr [ebp+PerformanceCount+4]
.text:0040175A xor eax, dword ptr [ebp+PerformanceCount]
.text:0040175D xor esi, eax
.text:0040175F cmp esi, edi
.text:00401761 jnz short loc_40176A
.text:00401763 mov esi, 0BB40E64Fh
.text:00401768 jmp short __save_cookie
.text:0040176A ;
.text:0040176A
.text:0040176A loc_40176A: ; CODE XREF: __security_init_cookie+6Dj
.text:0040176A test esi, ebx
.text:0040176C jnz short __save_cookie
.text:0040176E mov eax, esi
.text:00401770 shl eax, 10h
.text:00401773 or esi, eax
.text:00401775
.text:00401775 __save_cookie: ; CODE XREF: __security_init_cookie+74j
.text:00401775 ; __security_init_cookie+78j
.text:00401775 mov __security_cookie, esi
.text:0040177B not esi
.text:0040177D mov __security_cookie_complement, esi
.text:00401783 pop esi
.text:00401784
.text:00401784 _exit: ; CODE XREF: __security_init_cookie+2Ej
.text:00401784 pop edi
.text:00401785 pop ebx
.text:00401786 leave
.text:00401787 retn
.text:00401787 __security_init_cookie endp


Quant à la fonction __security_check_cookie, elle se contente de comparer le cookie sauvegardé sur la pile mémoire avec le __security_cookie contenu en dur dans le programme ; il est régénéré à chaque lancement du programme. Si les valeurs sont différentes une erreur est reportée par l’intermédiaire de la fonction __report_faufilure :

.text:00401090 __security_check_cookie proc near ; DATA XREF: _except_handler4+10o
.text:00401090 cmp ecx, __security_cookie
.text:00401096 jnz short loc_40109A
.text:00401098 rep retn
.text:0040109A ;
.text:0040109A
.text:0040109A loc_40109A: ; CODE XREF: __security_check_cookie+6j
.text:0040109A jmp __report_faufilure
.text:0040109A __security_check_cookie endp


Exemple :

int main(int argc, char **argv)
{
unsigned char buffer[64];

if (argc < 2)
{
printf("pas assez d'argument\n");
return 0;
}

//
// Etant donné que le cookie se situe à une adresse fixe, en fonction des allocations
// des buffers, il est possible de le lire directement en ajustant les pointeurs.
//

printf("Cookie offset = 0x%08X\n
Cookie value = 0x%02X%02X%02X%02X\n",
(int)&buffer + sizeof(buffer) + 4,
(buffer[sizeof(buffer) + 4 + 3]),
(buffer[sizeof(buffer) + 4 + 2]),
(buffer[sizeof(buffer) + 4 + 1]),
(buffer[sizeof(buffer) + 4]));

//
// Overflow !
//

printf("\nStack overflow reussi ...\n");

//
// Ici on utilise memcpy() pour copier le buffer, la taille est définie par la longueur
// de la chaîne de caractère du premier argument.
//

memcpy(buffer, argv[1], strlen(argv[1]));

printf("Cookie offset = 0x%08X\n
Cookie value = 0x%02X%02X%02X%02X\n",
(int)&buffer + sizeof(buffer) + 4,
(buffer[sizeof(buffer) + 4 + 3]),
(buffer[sizeof(buffer) + 4 + 2]),
(buffer[sizeof(buffer) + 4 + 1]),
(buffer[sizeof(buffer) + 4]));

return 0;
}


L'exécution a pour résultat :

\Projects\seh\release>seh.exe AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA
Cookie offset = 0x0012FF78
Cookie value = 0x5BDCB8C2

Stack overflow reussi ...

Cookie offset = 0x0012FF78
Cookie value = 0x41414141


Comme on peut le constater, on a un accès direct en écriture sur le cookie qui est sauvegardé dans la pile mémoire ; cela n'est plus possible depuis la sortie du Service Pack 1 (SP1 - lien ) pour Visual Studio. Sous Visual Studio 2005 SP1, de nouveaux pragmas ont fait leur apparition ; ils rendent le flag /GS beaucoup plus agressif et entreprenant d’après Michael Howard, un ingénieur de chez Microsoft ( lien )

Cela permet de forcer le cookie de la pile mémoire à être stocké dans la pile mémoire de la fonction en tant que première variable ; ce qui signifie qu’il sera stocké avant les variables locales de la fonction. Et par là même il sera donc beaucoup plus compliqué d'obtenir un accès en écriture contrairement au cas précédent voir même impossible pour le cas précédent.

Voici la syntaxe de ces pragmas :

#pragma strict_gs_check([push,] on )
#pragma strict_gs_check([push,] off )
#pragma strict_gs_check(pop)


Un pragma sert à passer des informations au compilateur directement depuis le code.


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 3] SafeSEH – 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