Theo De Raadt des projets visant à renforcer le mécanisme de protection de la mémoire W^X (Write XOR Execute). L'idée du mécanisme est que les pages de mémoire d'un processus ne peuvent pas être accessibles simultanément en écriture et en exécution. Ainsi, le code ne peut être exécuté qu'après l'interdiction de l'écriture, et l'écriture dans une page de mémoire est possible uniquement après l'interdiction de l'exécution. Le mécanisme W^X aide à protéger les applications dans l'espace utilisateur contre des attaques typiques réalisées par débordement de tampon, y compris contre les débordements de pile et est actif dans OpenBSD. .
Dès le début des travaux sur W^X, il était évident que c'était un long chemin, car il existe un nombre significatif d'applications utilisant JIT. Les implémentations JIT peuvent être classées en trois catégories :
- Commutant la mémoire entre les états W et X, acceptant le « coût » de l'appel système. .
- Créant des alias entre les paires d'affichages W et X d'une même mémoire.
- La variante la plus « sale » — nécessitant un modèle de mémoire W|X, permettant l'exécution et l'écriture simultanées.
Actuellement, il y a beaucoup moins de programmes utilisant la troisième variante et plus utilisant la première et la deuxième. Cependant, comme il était nécessaire d'exécuter des programmes avec JIT W|X (principalement Chromium et Iridium), une option de montage du système de fichiers « wxallowed » a été ajoutée, permettant d'utiliser la mémoire à la fois pour l'écriture et l'exécution, si le fichier ELF exécutable est marqué par le marqueur « wxneeded », et les applications elles-mêmes étaient en outre protégées en utilisant des mécanismes et pour restreindre la liste des appels système utilisés et des parties du système de fichiers accessibles à l'application.
Pour compliquer encore davantage l'exploitation des vulnérabilités dans de telles applications, un complément au mécanisme , qui vérifie si l'appel système est effectué à partir d'une page de mémoire accessible en écriture. Si la page est accessible en écriture, le processus est forcé de se terminer. Ainsi, un attaquant ne pourra pas utiliser les appels système et sera contraint d'essayer de trouver les gadgets nécessaires dans l'implémentation JIT ou même de faire un travail beaucoup plus difficile pour découvrir des ustensiles d'appels système directement à l'intérieur de .
Les processus Chrome/Iridium sont déjà assez bien protégés grâce à pledge et unveil, mais interdire l'utilisation d'appels système comme write(2) présente des avantages, car cela complique la tâche de l'attaquant. Cependant, des difficultés peuvent également survenir si la mise en œuvre JIT utilise des appels système natifs à partir de mémoire W|X. Il y a néanmoins des raisons d'espérer que cela ne posera pas de problème, car l'ABI a changé plusieurs fois, mais personne n'a jamais signalé de problèmes.
Les modifications sont déjà disponibles dans les instantanés réguliers de la branche OpenBSD-CURRENT, tous ceux qui sont intéressés sont invités à tester.
Theo a jugé nécessaire de commenter des nouvelles connexes concernant l'introduction d'un mode dans Chrome/Iridium. . Selon lui, cela est acceptable pour certains modèles d'utilisation, mais probablement pas pour tous, car dans ce mode, la charge sur le processeur augmentera clairement. Actuellement, Chrome fonctionnera principalement si l'on désactive « wxallowed » pour /usr/local, bien que des problèmes avec certaines extensions (comme ghostery) soient également probables. Quoi qu'il en soit, Theo espère que le fonctionnement complet en mode JITless sera atteint dans un avenir proche.
Source : opennet.ru
