Overflow buffer - Trova l'indirizzo di shellcode

10

Ho lavorato su Vulnerability-Overflow Buffer Lab da SEED ( Descrizione e attività del laboratorio ). L'ambiente è Ubuntu 12.04 a 32 bit. Si prega di prendere in considerazione il seguente codice:

/* stack.c */
/* This program has a buffer overflow vulnerability. */
/* Our task is to exploit this vulnerability */
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int bof(char *str)
{
    char buffer[24];
    /* The following statement has a buffer overflow problem */
    strcpy(buffer, str);
    return 1;
}
 int main(int argc, char **argv)
{
    char str[517];
    FILE *badfile;
    badfile = fopen("badfile", "r");
    fread(str, sizeof(char), 517, badfile);
    bof(str);
    printf("Returned Properly\n");
    return 1;
}

Ho scoperto che per sovrascrivere l'indirizzo di ritorno dovremmo sovrascrivere l'array partendo dal 36 ° posto, perché dovremmo saltare 24 byte (la dimensione dell'array) più 4 byte (per il precedente puntatore del frame) più 8 byte per alcuni dati del compilatore (non specificato per quale scopo). Ho calcolato questo con la differenza tra l'EBP e l'indirizzo del buffer (usando il debugger).

Mi sono reso conto che per passare al codice malevolo possiamo passare a qualsiasi indirizzo sulla slitta NOP. Per un valore sufficientemente grande l'attacco è riuscito. Ho provato a calcolare l'indirizzo minimo possibile. La logica (e il docente) ha detto che era EBP + 8 perché volevamo passare sia l'indirizzo di ritorno che il puntatore precedente del frame (4 byte ciascuno). Sfortunatamente l'attacco non è riuscito quando ho provato ad eseguirlo con quel valore. Ho trovato attraverso una ricerca esaustiva che l'indirizzo minimo possibile è 0xBFFFF168 , che è EBP + 48, e non capisco perché. Ho anche provato a eseguire l'attacco senza la slitta NOP e ho riscontrato problemi.

Qualcuno può spiegare per favore? Di seguito c'è una descrizione dello stack prima e dopo il superamento e alcuni valori aggiuntivi.

Grazie mille in anticipo.

14        strcpy(buffer, str);
(gdb) x/20x $sp
0xbffff100:    0x0804b008    0xbffff157    0x00000205    0xb7e34374
0xbffff110:    0xb7fc4ff4    0xb7fc4ff4    0x00000000    0xb7e1f900
0xbffff120:    0xbffff368    0xb7ff26b0    0x0804b008    0xb7fc4ff4
0xbffff130:    0x00000000    0x00000000    0xbffff368    0x080484ff
0xbffff140:    0xbffff157    0x00000001    0x00000205    0x0804b008
(gdb) next
16        return 1;
(gdb) x/20x $sp
0xbffff100:    0xbffff118    0xbffff157    0x00000205    0xb7e34374
0xbffff110:    0xb7fc4ff4    0xb7fc4ff4    0x90909090    0x90909090
0xbffff120:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff130:    0x90909090    0x90909090    0x90909090    0xbffff168
0xbffff140:    0x90909090    0x90909090    0x90909090    0x90909090
(gdb) p &buffer
$1 = (char (*)[24]) 0xbffff118
(gdb) p $ebp
$2 = (void *) 0xbffff138
(gdb) p $sp
$3 = (void *) 0xbffff100
    
posta alond22 07.02.2018 - 02:14
fonte

1 risposta

1

Le dimensioni effettive dello stack dipendono notevolmente dalle ottimizzazioni del compilatore e sono influenzate dalla presenza del debugger. In questo caso, non è necessario ridurre lo stack a ebp + 8, quindi non lo sovverrei.

Ricorda che contare sull'organizzazione dello stack per essere la stessa run to run non è più uno scenario di exploit realistico. In scenari più realistici, ti verrà chiesto di bypassare Nxbit / dep e ASLR, quindi contando sul tuo codice exploit per essere da qualche parte in particolare, puoi saltare a non tagliare comunque.

Se vuoi una versione gratuita dell'attacco con la slitta NOP, preferirei invece cercare un modo per rivelare un indirizzo senza arrestare il programma. In un esempio così piccolo, potrebbe non essere possibile.

    
risposta data 05.07.2018 - 18:15
fonte

Leggi altre domande sui tag