ma réponse concernait les archi IA32 avec segments ( oué bon, j'aurai pu peut etre précisé ) donc via l'execption "faute de segment" communément appelé SEGMENT_VIOLATION . je deteste fortement les modeles plats de mémoire selon le meme adage que l'on retrouve dans plein de domaine : si c facile pour les gentils c tout aussi facile pour les mechants.
tu proposais la gestion par le gestionnaire de pagination. il est logique de l'exception 14 soit levé dans ses cas. par contre, elle ne se leve que par page inaccessible ( donc soit 4ko ou 4Mo dans mon souvenir ). je vais lire le lien que tu as passé, il y a tjr des bonnes idées dans les docs constructeur.
PS. : Pour ce qui est des bouquins, laisse tomber ceux liés au 286, d'abord, c'est un processeur 16 bits, ensuite, je crois bien qu'il ne comporte pas de pagination.
merci du conseil :)
... le detail étant que j'ai commencé l'ASM, il y a plus de 15 ans avec des 286 et 386. ce qui fait que voulais me replonger dedans pour corroborer ma version. j'ai entre autres oeuvres sur le sujet, le Ziff-Davis sur les Opcode IA16 et IA32 , seule référence d'une époque où Intel avait du mal à avouer qu'il y avait des bugs dans ses processeurs.
plus sérieusement, tu as des données dans ES/DS et ta pile dans SS.
explique moi comment tu peux sortir de SS mais pas de ES/DS par overflow ?
si je ne m'abuse [SS:SP] est incremental et donc le pointeur de retour n'est pas accessible si l'on copie trop de données dans la pile.
Mais c'est pas ça, le principe d'une attaque par buffer overflow! Le principe, c'est justement de profiter de certaines données allouées sur la pile, donc dans le segment pointé par SS, pour écraser l'adresse de retour d'une fonction. La quantité de données qui y est copiée n'influe que sur la taille du buffer overflow nécessaire à l'attaque.
je t'ai proposé un exemple simplet de buffer overflow, non ?
le buffer overflow est l'injection de données dans l'espace de données.
Après à toi pour te débrouiller pour qu'il execute autre chose.
mais je te rappelle que la pile fonctionnement par empilement incremental ce qui veut dire qu'il faut decrementer ton pointeur de pile pour injecter une mauvaise adresse de retour.
dans le cadre d'un buffer overflow sur la pile, quand tu copie, ton pointeur de pile est incrementé. si par hasard tu envisage de faire un tour complet de la pile, tu devrais avoir soit un segment_violation soit un page_fault soit un bound_violation au moment d'arriver au bord supérieur.
quand tu sors de ta procedure, tout ce qui se trouve sur la pile est considéré comme perdu ( état incohérent ).
par contre, quand tu fais un malloc, tu alloues dans l'espace de données, un segment logique de mémoire qui est permanent : il ne peut donc en aucun cas se trouver sur la pile !!!! par contre, l'adresse de ce segment peut etre sur la pile.
dans le cadre d'une programmation avec des segment "physique" ( GDT/LDT ), un depassement de l'espace alloué provoquera une exception. l'injection de code se retrouve donc bloqué.
dans un modele plat, le code et les données sont sur le meme segment. donc, un depassement d'allocation logique ne se retrouvant pas arreté, se retrouve à potentiellement écrire dans son code ou sa pile.
[^] # Re: archi IA32
Posté par Mouns . En réponse au journal question : est-ce que la zone de code est modifiable. Évalué à 2.
ma réponse concernait les archi IA32 avec segments ( oué bon, j'aurai pu peut etre précisé ) donc via l'execption "faute de segment" communément appelé SEGMENT_VIOLATION . je deteste fortement les modeles plats de mémoire selon le meme adage que l'on retrouve dans plein de domaine : si c facile pour les gentils c tout aussi facile pour les mechants.
tu proposais la gestion par le gestionnaire de pagination. il est logique de l'exception 14 soit levé dans ses cas. par contre, elle ne se leve que par page inaccessible ( donc soit 4ko ou 4Mo dans mon souvenir ). je vais lire le lien que tu as passé, il y a tjr des bonnes idées dans les docs constructeur.
merci du conseil :)
... le detail étant que j'ai commencé l'ASM, il y a plus de 15 ans avec des 286 et 386. ce qui fait que voulais me replonger dedans pour corroborer ma version. j'ai entre autres oeuvres sur le sujet, le Ziff-Davis sur les Opcode IA16 et IA32 , seule référence d'une époque où Intel avait du mal à avouer qu'il y avait des bugs dans ses processeurs.
je t'ai proposé un exemple simplet de buffer overflow, non ?
le buffer overflow est l'injection de données dans l'espace de données.
Après à toi pour te débrouiller pour qu'il execute autre chose.
mais je te rappelle que la pile fonctionnement par empilement incremental ce qui veut dire qu'il faut decrementer ton pointeur de pile pour injecter une mauvaise adresse de retour.
dans le cadre d'un buffer overflow sur la pile, quand tu copie, ton pointeur de pile est incrementé. si par hasard tu envisage de faire un tour complet de la pile, tu devrais avoir soit un segment_violation soit un page_fault soit un bound_violation au moment d'arriver au bord supérieur.
quand tu sors de ta procedure, tout ce qui se trouve sur la pile est considéré comme perdu ( état incohérent ).
par contre, quand tu fais un malloc, tu alloues dans l'espace de données, un segment logique de mémoire qui est permanent : il ne peut donc en aucun cas se trouver sur la pile !!!! par contre, l'adresse de ce segment peut etre sur la pile.
dans le cadre d'une programmation avec des segment "physique" ( GDT/LDT ), un depassement de l'espace alloué provoquera une exception. l'injection de code se retrouve donc bloqué.
dans un modele plat, le code et les données sont sur le meme segment. donc, un depassement d'allocation logique ne se retrouvant pas arreté, se retrouve à potentiellement écrire dans son code ou sa pile.