Buffer, cookie, EBP, EIP, /GS protection
The /GS switch is an option of the compiler which adds to the prologue and to the epilogue a piece of code which makes it possible to guard against “classic” buffer overflows.
When the application is launched a cookie a 4 bytes integer and is calculated and placed in the data point of the loaded module. This cookie is an unsigned integer that, during the prologue protocol, is loaded into the stack just before EBP and EIP are saved.
[BUFFER][COOKIE][EBP][EIP]
During the epilogue, the cookie is compared to the initial cookie and if the latter is different it is concluded that there has been corruption and the program ends.
If we therefore try a buffer overflow, before overwriting EBP we will overwrite the cookie, which therefore makes it unusable.
Another protection generated by the switch /GS is that the variables are reorganized which implies that the buffer will be placed in high addresses of the frame and therefore above the other local variables preventing the latter from being overwritten.
A protection workaround would be for us to find, recalculate or destroy the value of this cookie in order to put it back in the right place at the right time. Indeed, the value of this cookie is very rarely a fixed value. It would be too easy.
We could also try to replace the cookie in the stack and in the .data with “our_cookie”, this being possible if we have write permissions to any location on the stack and in the .data.
Another way to bypass this protection is to try to throw an exception before the cookie is read in the epilogue. We thus end up there with a method already seen in the section concerning the SEH. This will of course work if SEH protection is used.
Le switch /GS est une option du compilateur qui ajoute au prologue et à l’épilogue un bout de code qui permet de se prémunir des buffers overflows « classiques ».
Quand l’application est lancée un cookie un entier de 4 octets et est calculé et placé dans le point data du module chargé. Ce cookie est un entier non signé qui, lors du protocole du prologue, est chargé dans la pile juste avant la sauvegarde de EBP et EIP.
[BUFFER][COOKIE][EBP][EIP]
Pendant l’épilogue, le cookie est comparé au cookie initial et si celui-ci est différent il est conclu qu’il y a eu corruption et le programme se termine.
Si nous essayons donc un buffer overflow, avant d’écraser EBP nous écraserons le cookie, ce qui le rend donc inexploitable.
Une autre protection engendrée par le switch /GS est que les variables sont réorganisées ce qui implique que le buffer va être placé dans des adresses hautes de la frame et donc au-dessus des autres variables locales empêchant l’écrasement de celle-ci.
Une solution de contournement protection serait que nous retrouvions, recalculions ou détruisons la valeur de ce cookie afin de la replacer au bon endroit au bon moment. En effet, la valeur de ce cookie est très rarement une valeur fixe. Cela serait trop facile.
Nous pourrions aussi essayer de remplacer le cookie dans la pile et dans le .data par « notre_cookie », cela étant possible si nous avons les droits d’écriture à n’importe quel emplacement de la pile et du .data.
Un autre moyen d’outrepasser cette protection est d’essayer de générer une exception avant la lecture du cookie dans l’épilogue. Nous nous retrouvons donc là avec une méthode déjà vu dans la section concernant le SEH. Cela fonctionnera bien sûr si la protection SEH est utilisée.