Amélioration de la protection mémoire dans IE10

IEBlog Français

Blog de l'équipe de développement de Windows Internet Explorer

Amélioration de la protection mémoire dans IE10

  • Comments 0

Internet Explorer 10 intègre d'importantes améliorations en termes de protection mémoire afin de contribuer à rendre les vulnérabilités plus difficiles à attaquer et à renforcer la sécurité des utilisateurs sur le Web parfois hostile. Ces améliorations augmenteront la difficulté et le coût de développement des attaques et ne facilitera pas la tâche des personnes malintentionnées.

Les programmes malveillants d'ingénierie sociale sont la méthode principale qu'utilisent les personnes malintentionnées pour faire parvenir leur code sur l'ordinateur de leur victime, car les vulnérabilités des navigateurs se sont raréfiées et sont devenues plus difficiles à attaquer au cours de ces dernières années. Toutefois, de plus en plus d'utilisateurs effectuant la mise à niveau vers IE9 et bénéficiant de la protection fournie par le filtre SmartScreen, les personnes malintentionnées éprouvent un regain d'intérêt pour les attaques directes du navigateur et de ses modules complémentaires.

Dans ce billet, j'explique l'environnement des menaces, j'examine les protections actuellement disponibles dans IE9 et j'explique comment les nouvelles protections mémoire d'IE10 procurent une sécurité renforcée.

Attaque des navigateurs Web

L'objectif d'un attaquant qui profite d'une vulnérabilité liée à la mémoire est de faire en sorte que l'exécution du chemin de code du navigateur se transforme en un code qu'il choisi lui-même. Pour ce faire, l'attaquant a besoin de deux éléments pour réussir. Du code doit être disponible sur l'ordinateur de la victime pour l'exécuter. Les techniques permettant d'obtenir ce code peuvent être regroupées en deux classes. Un attaquant peut placer son propre code malveillant en mémoire à l'aide de techniques, telles que le « heap spraying » (« organisation aléatoire des tas »). Il peut également sélectionner le code à exécuter (déjà présent en mémoire) à l'aide d'une technique appelée « Return Oriented Programming » (« Programmation orientée retour »).

L'attaquant doit également être capable d'attaquer une vulnérabilité qui permet à l'exécution du flux de code d'être altéré dès la conception, comme une vulnérabilité de dépassement de mémoire tampon. Il peut ensuite modifier le chemin du code pour qu'il accède directement à l'adresse du code qu'il souhaite exécuter.

Lors d'une attaque de dépassement de mémoire tampon typique, un jeu de données soigneusement conçu est placé sur la pile du thread, ce qui provoque un dépassement de la mémoire tampon qui lui est affectée et un remplacement d'autres structures de données. Les attaquants tentent de remplacer les structures, telles que les enregistrements du gestionnaire d'exceptions ou l'adresse de retour de la fonction, ce qui leur permettrait de modifier le flux de code pour l'orienter sur l'emplacement en mémoire de leur choix.

Diagramme indiquant que lorsque la quantité de données écrites sur une mémoire tampon locale dépasse son allocation, des parties importantes de la pile peuvent être remplacées, ce qui peut entraîner une défaillance. En soumettant des données conçues avec soin, un attaquant peut remplacer l'adresse de retour, transformant ainsi l'exécution du flux de code en un emplacement mémoire arbitraire.

D'autres types d'attaques incluent des vulnérabilités de type « use-after-free », qui obligent l'application à accéder à un objet libéré dont la mémoire a été réutilisée dans un autre but.

Défense du navigateur

Les technologies de protection mémoire fournissent une première ligne de défense pour empêcher les attaquants de parvenir à leurs fins. Ces technologies sont là pour rendre l'attaque des vulnérabilités plus difficile, moins fiable et dans certains cas, impossible. Les protections mémoire visent à terminer en toute sécurité le processus d'un navigateur subissant une attaque avant qu'une attaque réussisse à exécuter le code de l'attaquant. Dans de nombreux cas, les protections donnent aux fournisseurs le temps nécessaire pour produire et distribuer un correctif avant que la vulnérabilité ne puisse être utilisée pour provoquer des dommages.

Les technologies de prévention mémoire employées par Internet Explorer ont évolué avec le temps dans le but de renforcer la défense contre les nouvelles techniques d'attaque au fur et à mesure de leur développement et de leur utilisation. De nombreuses défenses, telles que l'indicateur de compilateur /GS, ont été utilisées par les versions précédentes d'Internet Explorer, mais sont actualisées et améliorées au fil du temps. Certaines défenses, telles que ForceASLR (décrite succinctement plus loin) sont nouvelles dans IE10 et s'appuient sur les nouvelles fonctionnalités du système d'exploitation.

Mesures de prévention du temps de compilation

Les mesures de prévention du compilateur sont à la disposition des développeurs logiciels et il est recommandé de les appliquer. Lors du développement d'Internet Explorer, l'équipe Internet Explorer inclut ces mesures de prévention qui sont une condition requise de nos vérifications SDL (Security Development Lifecycle). Nous encourageons les développeurs logiciels à adopter leur propre processus SDL qui inclut l'implémentation de ces mesures de prévention du temps de compilation.

L'indicateur /GS a été introduit pour la première fois dans Visual Studio .NET 2002 et a été utilisé par toutes les versions d'IE prises en charge. Il s'agit d'une technologie de compilateur qui ajoute une fonctionnalité de détection de saturation de mémoire tampon à la pile d'une application. Les secrets de sécurité connus sous le nom de « canaris » sont ajoutés aux limites de la pile de l'application au moment de l'exécution. Par exemple, un canari placé entre la mémoire tampon d'une pile et une adresse de retour sera remplacé par une attaque de dépassement de mémoire tampon qui a pour cible l'adresse de retour. Cela permet au processus de détecter si un dépassement a eu lieu. Une exception est alors levée et le processus peut se terminer en toute sécurité avant l'exécution du code de l'attaquant.

Diagramme illustrant la façon dont un secret de sécurité est placé entre les variables locales et l'adresse de retour. Avant le retour de la fonction, la valeur du secret est comparée à la valeur originale. Si la comparaison échoue, une exception est levée et le processus peut se terminer en toute sécurité.

Ce concept de protection de base a été amélioré dans chaque nouvelle version de Visual Studio. La dernière version de l'indicateur /GS amélioré, utilisée par Internet Explorer 9+ comprend des heuristiques nettement améliorées pour protéger un plus grand nombre de fonctions, notamment les tableaux non pointeurs et les structures de données pures. En outre, l'optimisation renforcée a permis d'éliminer les vérifications inutiles, réduisant ainsi les coûts de la défense en termes de performances.

L'indicateur /SAFESEH est une option de l'Éditeur de liens qui fournit une méthode permettant aux gestionnaires d'exceptions inscrits d'une application d'être stockés dans une table de recherche à un emplacement sécurisé en mémoire. Dans le cas d'une exception, les adresses du gestionnaire d'exceptions qui se trouvent sur la pile de l'application sont comparées à la table de recherche. Si les valeurs ne correspondent pas, le processus prend fin.

Diagramme montrant que les adresses d'inscription des exceptions sont comparées aux valeurs stockées dans la recherche. Si les valeurs ne correspondent pas, une exception est levée et le processus se termine.

Le problème posé par l'indicateur /SAFESEH est qu'il nécessite que tous les modules DLL adoptent la protection afin de protéger de façon fiable le processus. Si un module n'adopte pas la protection, celle-ci est moins efficace. Alors que l'ensemble du code de Microsoft est compilé avec SAFESEH comme le processus SDL le requiert, les modules complémentaires tiers risquent de ne pas être compilés avec l'indicateur.

L'indicateur /DYNAMICBASE est une option de l'Éditeur de liens qui conduit une application à adhérer à la mesure de prévention d'un système d'exploitation, connue sous le nom de randomisation du format d'espace d'adresse (ASLR). Elle fera l'objet d'une brève description plus loin dans ce billet.

Tout comme la limitation /SAFESEH, le problème lié à l'indicateur /DYNAMICBASE réside dans le fait que les modules DLL qui n'adoptent pas cette protection réduisent la valeur d'ASLR en tant que mesure de prévention contre les attaques. Les modules qui se trouvent à un emplacement prévisible peuvent être la cible d'un attaquant. Et une attaque peut n'avoir besoin que d'une seule cible prévisible comme celle-ci. De nombreuses attaques récentes ciblent les modules complémentaires des navigateurs qui n'adoptent pas la protection d'ASLR. Par exemple, l'attaque menée contre Adobe Reader et Acrobat l'année dernière s'appuyait sur l'emplacement prévisible des fonctions au sein d'un module nommé icucnv36.dll qui n'avait pas adopté ASLR.

Mesures de prévention du temps d'exécution

Les mesures de prévention du temps d'exécution permettent au système d'exploitation de mieux sécuriser le processus.

DEP/NX est une mesure de prévention du système d'exploitation qui s'appuie sur les fonctionnalités de sécurité de la clé (Data Execution Prevention (DEP) ou No eXecute) des processeurs modernes. Cette mesure de prévention permet de marquer les pages mémoire comme non exécutables (données). Le processeur refusera d'exécuter du code portant cette mention sur une page mémoire.

Dans la deuxième phase d'une attaque mémoire, un attaquant peut essayer d'exécuter son propre code qu'il a ajouté à une page de données en mémoire. Dans les cas où la page de données a été marquée comme non exécutable, le code de l'attaquant ne réussira pas à s'exécuter et le processus pourra se terminer en toute sécurité.

DEP/NX a d'abord été pris en charge par défaut dans IE8 et il le demeure dans IE10.

SEHOP est une mesure de prévention du temps d'exécution qui fournit un mode de protection contre la falsification des gestionnaires d'exceptions, comme l'indicateur de compilateur /SAFESEH. Cette protection fonctionne en insérant un enregistrement d'exception symbolique sous la forme de l'enregistrement de fin dans la liste des gestionnaires d'exceptions du thread. Dans le cas d'une exception, la liste des gestionnaires d'exceptions est parcourue pour s'assurer que l'enregistrement symbolique est accessible. Dans le cas contraire, cela indique que la chaîne des gestionnaires d'exceptions est endommagée et le processus se terminera en toute sécurité. Contrairement à SAFESEH, SEHOP ne requiert pas que chaque module adopte la protection. Par conséquent, il assure une protection même si les modules complémentaires n'ont pas été compilés avec les indicateurs les plus sûrs.

SEHOP a d'abord été pris en charge dans IE9 et il le demeure dans IE10.

La randomisation du format d'espace d'adresse (ASLR) a d'abord été introduite dans Windows Vista et a été améliorée de façon significative dans Windows 8. ASLR attribue aux applications une adresse mémoire de base aléatoire lorsqu'elles sont initialement chargées en mémoire. En outre, d'autres structures mémoire, telles que PEB (Process Environment Blocks), TEB (Thread Environment Blocks), les piles et les tas (heap) sont également attribués pour rendre aléatoires les emplacements en mémoire.

Le fait de rendre aléatoire l'emplacement des objets et des fonctions en mémoire permet d'empêcher un attaquant de découvrir où ils se trouvent, ce qui permet de combattre une technique appelée « Return Oriented Programming » (« Programmation orientée retour »). Ce caractère aléatoire peut être considéré comme la sécurisation contre la charge de l'attaquant par une serrure à combinaison. Si un attaquant n'a pas la combinaison, il n'a droit qu'à une seule chance pour deviner. S'il se trompe, l'attaque échoue et le processus se termine en toute sécurité.

L'illustration suivante présente la façon dont les principaux composants système sont chargés dans des adresses mémoire aléatoires au démarrage du système.

Diagramme présentant la façon dont l'emplacement mémoire physique de différentes DLL système change entre un premier démarrage et un second

ASLR dans Windows 8 a connu un grand nombre d'améliorations et toutes sont utilisées par Internet Explorer 10.

Toutes les allocations ascendantes et descendantes sont maintenant rendues aléatoires à l'aide de 8 bits d'entropie. Cette amélioration réduit considérablement les régions mémoire prévisibles, notamment VirtualAlloc et MapViewOfFile.

La randomisation du format d'espace d'adresse d'entropie élevée (HEASLR) tire parti de l'augmentation de l'espace d'adresse 64 bits et attribue plus de bits à l'entropie. Cela a pour effet d'augmenter considérablement le nombre d'adresses potentielles pouvant être assignées à un processus 64 bits. Tous les processus 64 bits peuvent adopter l'entropie augmentée rendue disponible par HEASLR. Les processus peuvent l'adopter soit durant l'édition de liens (/HIGHENTROPYVA), soit lors du chargement via une nouvelle option d'exécution du fichier image (« Image File Execution »).

Par défaut, le navigateur de style Metro s'exécute en mode 64 bits sur des ordinateurs 64 bits, ce qui procure un espace d'adresse beaucoup plus grand et par conséquent, une disposition mémoire aléatoire plus importante.

ForceASLR est sans conteste le changement le plus important apporté à ASLR dans Windows 8. ForceASLR est une nouvelle option de chargement utilisée par Internet Explorer 10 pour demander au système d'exploitation de randomiser l'emplacement de tous les modules chargés par le navigateur, même si un module donné n'a pas été compilé par l'indicateur /DYNAMICBASE. La protection ForceASLR a été ajoutée au noyau Windows 8 et la fonctionnalité est maintenant disponible sous la forme d'une mise à jour de Windows 7 qui est installé lors de l'installation d'Internet Explorer 10 sur cette plateforme.

Pour garantir la compatibilité avec cette fonctionnalité et pour fournir une protection par la randomisation mémoire aux anciennes versions d'Internet Explorer qui ne prennent pas en charge ForceASLR, nous continuons à recommander aux développeurs de modules complémentaires d'utiliser l'indicateur /DYNAMICBASE.

Résumé

J'espère que cette brève vue d'ensemble des protections mémoire présentes dans Windows 8 et dans Internet Explorer 10 s'est révélée utile. Fondamentalement, nous avons effectué beaucoup d'autres manipulations pour renforcer la sécurité, mais un grand nombre d'entre elles sont tellement ésotériques que nous ne leur avons même pas donné de nom. Nous annoncerons d'autres mesures relatives à la sécurité dans de futurs billets. Alors, gardez un œil sur les mises à jour, car nous poursuivons notre mission pour mettre au point une plateforme de navigation Web sécurisée.

—Forbes Higman, Chef de projet de la sécurité, Internet Explorer

  • Loading...