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

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

---

Résumé : ASLR vise à générer aléatoirement les adresses de la pile qui sont susceptibles d’être utilisées lors de l’exploitation d’une vulnérabilité. La protection NX a elle en vue d’empêcher l’exécution de code sur les espaces de données réservés aux données. UAC est un système permettant entre autres à un utilisateur de valider ou non l'exécution d'un programme. - Lire l'article



Le mécanisme ASLR ( Address Space Layout Randomization ) a vu le jour avec la version Beta 2 de Microsoft Windows Vista, il a été à l'origine d'une vive polémique de par le fait que Microsoft le qualifia d’innovation en matière de sécurité alors que le concept ASLR existait déjà depuis plusieurs années sous les systèmes d'exploitation Open Source de type GNU/Linux avec PaX ( lien ).

L’ASLR tout comme PaX, visent tous les deux à générer de façon aléatoire les adresses affectées aux modules que ce soit pour la stack ou pour tous les autres types d’adresses qui sont susceptibles d’être utilisés lors de l’exploitation d’une vulnérabilité.

Une deuxième explication à cette polémique se trouvant tout naturellement dans la faiblesse d’implémentation du mécanisme au niveau des systèmes Microsoft Windows Vista dès la version Beta 2 ; il faut savoir également que la plupart des attaques sur le mécanisme ASLR de Microsoft Windows Vista sont basées sur des probabilités et du brute force.

Les détails de la polémique sont disponible sur le blog de Michael Howard ( lien ), aussi connu pour être l’auteur du livre « Ecrire du code sécurisé » ; on peut voir sur ce blog l’équipe de PaX qui poste des commentaires indiquant que Microsoft n’a rien inventé en ce qui concerne l’ASLR ( voir le tutoriel Renforcement des fonctions de sécurité du noyau Linux sur Secuobs - lien ).

Les attaques deviennent de plus en plus compliquée à cause de la complexité des techniques de prévention utilisées dans le domaine de la sécurité ; cela ne signifie cependant pas pour autant que l'exécution d'un stack overflow basique n'est plus possible. Chose que l’on constate de plus en plus en consultant les exploits publiques disponible sur des sites tels que milw0rm ( lien ).


NX

La fonctionnalité matérielle No eXecution a quant à elle vu le jour en premier lieu pour les processeurs AMD64 sous le nom de « No eXecution bit » puis la technique a été reprise plus tard par Intel avec le nom XD pour « eXecution Disabled » ; c'est cette technique qui permet par exemple d'offrir aux utilisateurs des systèmes d'exploitation Microsoft Windows les plus récents l'activation ou non du Hardware Data Execution Prevention ; ce qui permet ou pas l’exécution directe de code sur la stack ou le heap, voici deux liens dans lesquels la technologie dite NX est présentée ( lien - lien ).

Cette protection est activée par défaut pour les services de Microsoft Windows Vista mais également sur les exécutables compilés avec l’option /NXCOMPAT auprès du compilateur ; elle a pour objectif d’empêcher l’exécution de code malveillant sur les espaces de données théoriquement strictement utilisés pour les données tels que la stack ou la heap.

int main(int argc, char **argv)
{
int r_edx;

//
// Via l’opcode CPUID on lit le bit NX indiquant si la
// technologie est présente ou pas.
//
_asm
{
mov eax, 0x80000001
cpuid
mov r_edx, edx
}

if (r_edx | (1<<20)) printf("NX Enabled\n");
else printf("NX Disabled");

return 0;
}


Cette protection étant matérielle il est impossible de la contourner directement sauf si l’on arrive à changer le bit, mais cette action demanderait beaucoup trop de droits, ce qui est impossible dans un cas d’exploitation étant donné qu’on ne s’intéresse qu'à la partie logicielle.

Pour l'exemple suivant, on prend une simulation d’authentification que l'on va contourner grâce a un « off by one ». Le méthode est simple, l’authentification utilise une clef privée pour encoder/décoder le mot de passe et il est donc nécessaire ici de savoir comment récupérer la clef :

int main(int argc, char **argv)
{

unsigned char key[16];
unsigned char buffer[32];

//
// Initialize key
//

memcpy(key, "privatekey", 10);

printf("Login: ");
memcpy(buffer, argv[1], (size_t)strlen(argv[1])); // Overflow si >= 32;
printf("Vous essayez de vous connecter sur : %s\n", buffer);

//for(size = 0; size < sizeof(buffer); size++)
//{
// [...]
// Ici on utilise un algorithme quelconque qui utilise
// la variable "key" pour encrypter le nom d'utilisateur et le comparer avec le
// mot de passe.
//}

printf("Bye bye.\n");
return 0;
}


L'exécution donnant le résultant suivant :

>offbyone.exe secuobs
Login: You are trying to login at: secuobs
Bye bye.


Voici maintenant comment on peut récupérer la clef privée dans ce contexte grâce à un off by one :

> offbyone.exe aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Login: You are trying to login at: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaprivatekey@
Bye bye.


Techniquement parlant une chaîne de caractères se termine par un octet null, si l’on arrive à écrire après cet octet null la chaîne devient plus longue. Dans le cas présent on alloue 32 octects qu’on remplit un à un, on oublie de laisser l'octet null qui indique que la chaîne de caractère est finie. Ce qui explique pourquoi la clef est visible lors du printf().


UAC :

L’équipe de Symantec ( lien ) explique comment l'UAC peut être contourné. Tout simplement en faisant un abus de confiance auprès de l’utilisateur, il propose de télécharger le malware sous un nom aléatoire. Ce dernier va changer un raccourci dans le menu démarré en utilisant le même nom, ainsi quand l’utilisateur croira lancer son programme préféré et qu’il verra l'invite UAC s’afficher il aura à choisir s'il veut lancer ou non le programme après avoir reconnu son nom alors qu’il ne s’agira pas de ce dernier qui sera exécuté au final.


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

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