En dehors de la vision d'horreur que constituerait un retour à la mémoire segmentée, et tres certainement les complications au niveau de l'OS, et de toutes les applications (puisque sous Unix on a une vision lineaire de la RAM) (va-t-il falloir utiliser "far pointer" en plus de "pointer" ? :) ), l'impossibilité d'executer du code dans la pile ou le tas est toute relative.
Voila comment j'imagine les choses:
Si je ne m'abuse, pour exploiter un BufferOverflow, il fallait pouvoir:
1) placer du code quelque part (pile ou tas)
2) réécrire dans la pile le mot de 32 bits qui contient l'adresse de retour de la fonction, pour qu'elle pointe sur la zone 1)
La fin de toute fonction est normalement l'instruction RET qui dépile l'addresse EIP de retour et saute à cette adresse (dans le segment de code CS). Effectivement, separer CS de DS ou SS (les segment de donnée ou de pile) empeche de faire cela directement. Mais il existe une autre instruction, RETF (RET Far) qui dépile EIP et CS, et permet donc d'outrepasser la séparation de segments en changeant la valeur de CS.
Cette instruction, comme RET, est codée sur 1 octet (0xCB). Une analyse du binaire attaqué permet surement de trouver un octet de cette valeur quelque part dans le code, dont on puisse injecter l'adresse. À partir de là, la sequence d'attaque deviendrait:
1) placer du code quelquepart dans la pile ou le tas
2) réécrire dans la pile l'adresse de retour de fonction, pour qu'elle pointe vers un octet dans le segment de code, codant pour RETF
3) réécrire le double mot précédent de la pile, pour qu'il contienne le segment+adresse de la zone 1.
Le RET standard de la fonction va dépiler 2, et executer le RETF a l'adresse indiquée. Ce RETF va lui-meme dépiler la valeur dans 3, et faire un saut long vers la zone 1, en ayant modifié le segment de code CS.
C'est bien sur plus difficile comme attaque, mais je pense que ca reste possible.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par daggett . En réponse à la dépêche Premier patch 'NX' pour le noyau Linux. Évalué à 9.
En dehors de la vision d'horreur que constituerait un retour à la mémoire segmentée, et tres certainement les complications au niveau de l'OS, et de toutes les applications (puisque sous Unix on a une vision lineaire de la RAM) (va-t-il falloir utiliser "far pointer" en plus de "pointer" ? :) ), l'impossibilité d'executer du code dans la pile ou le tas est toute relative.
Voila comment j'imagine les choses:
Si je ne m'abuse, pour exploiter un BufferOverflow, il fallait pouvoir:
1) placer du code quelque part (pile ou tas)
2) réécrire dans la pile le mot de 32 bits qui contient l'adresse de retour de la fonction, pour qu'elle pointe sur la zone 1)
La fin de toute fonction est normalement l'instruction RET qui dépile l'addresse EIP de retour et saute à cette adresse (dans le segment de code CS). Effectivement, separer CS de DS ou SS (les segment de donnée ou de pile) empeche de faire cela directement. Mais il existe une autre instruction, RETF (RET Far) qui dépile EIP et CS, et permet donc d'outrepasser la séparation de segments en changeant la valeur de CS.
Cette instruction, comme RET, est codée sur 1 octet (0xCB). Une analyse du binaire attaqué permet surement de trouver un octet de cette valeur quelque part dans le code, dont on puisse injecter l'adresse. À partir de là, la sequence d'attaque deviendrait:
1) placer du code quelquepart dans la pile ou le tas
2) réécrire dans la pile l'adresse de retour de fonction, pour qu'elle pointe vers un octet dans le segment de code, codant pour RETF
3) réécrire le double mot précédent de la pile, pour qu'il contienne le segment+adresse de la zone 1.
Le RET standard de la fonction va dépiler 2, et executer le RETF a l'adresse indiquée. Ce RETF va lui-meme dépiler la valeur dans 3, et faire un saut long vers la zone 1, en ayant modifié le segment de code CS.
C'est bien sur plus difficile comme attaque, mais je pense que ca reste possible.