En regardant les titres des présentations des conférences de sécurité ou les articles traitants de JIT-Spraying et ROP on pourrait penser que pour exécuter du code sur une machine ou élever ses privilèges il faut déployer des techniques de plus en plus complexes.
Ce raisonnement est correct à la vue des protections comme l’ASLR, DEP, SEHOP, … Malheureusement, il existe toujours des types de vulnérabilités qui ne peuvent pas être protégées d’une exploitation via de telles techniques: celles liées au design ou à l’implémentation de certaines fonctionnalités par le développeur de l’application. Récemment deux vulnérabilités de ce type ont été publiées: PAM MOTD sous Ubuntu et une vulnérabilité touchant iTunes pour Windows.
La vulnérabilité touchant le module PAM sous Ubuntu est due au fait que du code exécuté en tant que root réassigne un dossier situé dans le répertoire personnel de l’utilisateur actuel à ce dernier après en avoir modifié le contenu. En apparence cela ne pose pas de problème puisque le dossier appartient déjà à l’utilisateur actuel, sauf… dans le cas où le dossier est en réalité un lien symbolique. Un attaquant ayant un accès restreint à la machine (local, ssh, … mais avec un compte d’utilisateur lambda) peut alors faire pointer ce lien sur des fichiers tels que /etc/passwd et /etc/shadow afin d’obtenir les droits permettant de les modifier pour ajouter un utilisateur root. Ici la vulnérabilité a été corrigée en appelant les appels systèmes setreuid() et setreguid() afin de perdre les droits root avant de modifier le fichier.
La faille découverte dans iTunes résulte d’une mauvaise utilisation de la fonction LoadLibrary. Lors de la lecture d’un fichier, iTunes va tenter de charger une bibliothèque depuis le répertoire courant, qui sera celui où se trouve ce fichier. Ce fichier pouvant être accédé via le protocole WEBDAV, un attaquant peut exécuter du code à distance du moment qu’un utilisateur ouvre le fichier se trouvant dans le même répertoire que la bibliothèque qui sera chargée par iTunes. De nombreuses autres applications sont sujettes au même problème. Dans le cas d’iTunes, le code chargeant la bibliothèque a été supprimé mais on peut également se prémunir de telles vulnérabilités via des règles dans AppLocker/GPO par exemple.
Il faut bien noter que ces deux vulnérabilités ne sont pas le résultat de nouvelles techniques d’exploitation (en 2000 une vulnérabilité liée à SearchPath/LoadLibrary avait déjà été publiée), mais d’erreurs d’implémentation au moment du développement des applications.