Théo De Raadt prévoit de renforcer le mécanisme de protection de la mémoire W^X (Write XOR Execute). L'essence du mécanisme est que les pages de la mémoire de processus ne sont pas accessibles simultanément pour l'écriture et l'exécution. Ainsi, le code ne peut être exécuté qu'après la désactivation de l'écriture, et l'écriture sur une page mémoire n'est possible qu'après la désactivation de l'exécution. Le mécanisme W^X aide à protéger les applications de l'espace utilisateur contre les attaques courantes par débordement de tampon, y compris les débordements de pile, et est actif dans OpenBSD. .
Dès le début des travaux sur W^X, il était clair que le chemin était long, puisqu'il existait un nombre important d'applications utilisant JIT. Les implémentations JIT peuvent être divisées en trois catégories :
- Commutation de la mémoire entre les états W et X, en acceptant le « coût » de l'appel système .
- Création d'alias entre une paire de mappages W et X de la même mémoire.
- L’option la plus « sale » est celle qui nécessite un modèle de mémoire W|X qui permet l’enregistrement et l’exécution simultanés.
Actuellement, il existe beaucoup moins de programmes utilisant la troisième option et davantage utilisant la première et la deuxième. Cependant, comme il était nécessaire d'exécuter des programmes avec W|X JIT (principalement Chromium et Iridum), une option de montage du système de fichiers "wxallowed" a été ajoutée, ce qui permettait d'utiliser la mémoire simultanément pour l'écriture et l'exécution, au cas où l'exécutable ELF le fichier est marqué avec le marqueur « wxneeded », et les applications elles-mêmes ont en outre été protégées à l'aide de mécanismes и pour limiter la liste des appels système utilisés et des parties du système de fichiers disponibles pour l'application, respectivement.
Pour compliquer davantage l'exploitation des vulnérabilités dans de telles applications, un ajout au mécanisme est proposé , qui vérifie si l'appel système est exécuté à partir d'une page mémoire inscriptible. Si la page est accessible en écriture, le processus est forcé de se terminer. De cette façon, un attaquant ne pourra pas exploiter les appels système et sera obligé d'essayer de trouver les gadgets nécessaires dans l'implémentation JIT, ou même d'effectuer le travail plus difficile de détection des stubs d'appel système directement à l'intérieur. .
Les processus Chrome/Iridium sont déjà protégés de manière assez fiable à l'aide de Gage et Unveil, mais supprimer la possibilité d'utiliser, par exemple, l'appel système write(2) présente évidemment un certain avantage, car cela crée des difficultés supplémentaires pour l'attaquant. Cependant, des difficultés peuvent également survenir si l'implémentation JIT utilise des appels système natifs de la mémoire W|X. Cependant, il y a lieu d'espérer que ce ne sera pas le cas, puisque l'ABI a été modifié à plusieurs reprises, mais personne n'a jamais signalé de problèmes.
Les modifications sont déjà disponibles dans des instantanés réguliers de la branche OpenBSD-Current, toutes les personnes intéressées sont invitées à les tester.
L'actualité connexe concernant l'apparition du mode dans Chrome/Iridium mérite un commentaire séparé de la part de Theo . De son point de vue, cela est acceptable pour certains modèles d'utilisation, mais probablement pas pour tous, puisque ce mode va évidemment augmenter la charge du processeur. Actuellement, Chrome fonctionnera principalement si vous désactivez « wxallowed » pour /usr/local, bien qu'il puisse y avoir des problèmes avec certaines extensions (ghostery en est un exemple). D'une manière ou d'une autre, Theo espère que le travail à part entière en mode JITless sera amené à un état pleinement opérationnel dans un avenir proche.
Source: opennet.ru