Ce qui se passe est l'interaction entre un programme et le serveur X. Le programme peut obliger le serveur X à rentrer dans une boucle récursive dont il contrôle la profondeur. Lorsqu'un programme devient récursif, il se met à prendre de la place sur le stack pour pouvoir revenir à son état d'origine après les différents appels de fonction.
Le bug se produit lorsque le stack descend tellement bas qu'il tombe sur un espace d'adressage déjà utilisé et controllé par l'application.
Dans ce cas, il suffit à l'application d'écrire dedans pour écrire dans le stack du serveur X, ce qui donne très facilement un contrôle total du serveur X.
A mon sens il y a deux bugs ici :
- Le serveur X ne devrait pas pouvoir rentrer en récursion arbitraire avec des entrées utilisateurs; Si récursion il y a, elle doit être bornée avec des limites raisonnable. Si il n'y avait pas eu de possibilité d'exploitation, ça aurait tourné en local DoS, ce qui n'est pas un comportement valable non plus.
- Le noyau ne devrait pas autoriser le stack à s'approcher d'aussi près de pages déjà allouées. C'est d'ailleurs ce qui a été implémenté comme solution : une page de garde est rajoutée au sommet du stack à chaque agrandissement afin d'éviter que l'application ne se mette à écrire dans des zones qui ne sont pas dans le stack.
C'est d'ailleurs quelque chose que windows fait depuis longtemps pour séparer les différents stacks des différents threads d'un même processus.
# Explication un peu plus complete
Posté par Aris Adamantiadis (site web personnel) . En réponse à la dépêche Problème de sécurité entre le serveur X et le noyau. Évalué à 10.
Le bug se produit lorsque le stack descend tellement bas qu'il tombe sur un espace d'adressage déjà utilisé et controllé par l'application.
Dans ce cas, il suffit à l'application d'écrire dedans pour écrire dans le stack du serveur X, ce qui donne très facilement un contrôle total du serveur X.
A mon sens il y a deux bugs ici :
- Le serveur X ne devrait pas pouvoir rentrer en récursion arbitraire avec des entrées utilisateurs; Si récursion il y a, elle doit être bornée avec des limites raisonnable. Si il n'y avait pas eu de possibilité d'exploitation, ça aurait tourné en local DoS, ce qui n'est pas un comportement valable non plus.
- Le noyau ne devrait pas autoriser le stack à s'approcher d'aussi près de pages déjà allouées. C'est d'ailleurs ce qui a été implémenté comme solution : une page de garde est rajoutée au sommet du stack à chaque agrandissement afin d'éviter que l'application ne se mette à écrire dans des zones qui ne sont pas dans le stack.
C'est d'ailleurs quelque chose que windows fait depuis longtemps pour séparer les différents stacks des différents threads d'un même processus.