Brad Spengler, le leader du projet grsecurity, exprimait, lors de son intervention au SSTIC 2016, son agacement à lier la sécurité d'une application à son implémentation. Pour lui, la sécurisation d'une application ne doit pas se faire via la recherche de bugs dans cette dernière, mais doit être assurée par la plateforme sur laquelle elle s'exécute. L'ASLR fait partie de ces évolutions proposées par les systèmes d'exploitation, dans le but de complexifier l'exploitation de failles applicatives.
Au milieu des années 2000, l'exploitation de failles applicatives en userland était relativement simple, car il n'existait que très peu de mécanismes de protection. Ces dernières sont venues initialement des fondeurs avec le DEP, Data Protection Execution, visant à partitionner l'espace mémoire en pages exécutables ou non d'une application. Notamment, les zones mémoires hébergeant la pile ou le tas ne sont plus exécutables. Pour contourner ces protections, une nouvelle génération d'exploit a vu le jour, visant à utiliser le code exécutable présent dans l'application défaillante en modifiant, par exemple, le flux d'exécution vers des fonctions connues de la libc. Cette technique d'exploitation, connue sous le nom de return to libc, repose sur le fait que l'adresse de la fonction visée est prédictible à l'exécution de l'application. L'Address Space Layout Randomization, ou ASLR constitue une réponse intéressante du système d'exploitation, en positionnant de...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
