return-to-libc non può ottenere l'indirizzo della funzione di sistema

2

Sto cercando di sfruttare il mio codice, solo per imparare come funziona la tecnica "return-to-libc".

Sto seguendo un tutorial che dice fondamentalmente che per usare questo, devo trovare l'indirizzo della funzione che voglio usare.

Per rimanere su classico, ho scelto di usare la funzione "sistema" per ottenere una shell.

I miei passi per trovare questo indirizzo sono:

  1. esegui gdb con come argomento il nome dell'eseguibile che voglio sfruttare. per esempio. "$ gdb test"
  2. inserire un punto di interruzione per arrestare il codice caricato. Diciamo "b principale" al prompt di gdb
  3. esegui il codice che si ferma al punto di interruzione "r"
  4. ottieni l'indirizzo con "p system"

Questo è un esempio di ciò che ho fatto:

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".<br>

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x2779b0** <system>
(gdb) q


GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x1459b0** <system>

Sembra che ogni volta che avvio gdb ottengo un indirizzo diverso? Qualcuno può spiegarmi perché?

Questa è una funzione di mitigazione creata nel mio kernel / linux per impedire questo utilizzo della tecnica di exploit?

Più tardi, facendo ricerche su google ho finalmente trovato qualcosa che si adatta un po 'al mio scenario. Sembra esistere una funzionalità chiamata " randomizzazione del layout dello spazio degli indirizzi del kernel " che è simile in qualche modo a quello che io sto vivendo. Tuttavia, se capisco completamente che cosa sia questa randomizzazione del layout dello spazio del kernel, dovrei provare questo beaviour una volta ogni volta che ricarico il kernel, invece ho questo comportamento ogni volta che avvio il codice attraverso gdb. Infatti, costruendo il seguente codice semplice, il comportamento strano e sperimentato sembra non essere lì:

#include <stdio.h>
#include <stdlib.h>

int main()
{
 printf("%p\n", (void*)system);
}

Questo codice dovrebbe generare l'indirizzo della funzione system (). Provandolo, produce ogni volta lo stesso indirizzo. Sembra che questo strano comportamento sia correlato al gdb, ma non ne sono sicuro .... Sono confuso.

    
posta alessandro 29.04.2016 - 17:18
fonte

1 risposta

1

Sembra che abbia trovato una risposta da solo, almeno una sorta di Bene, come sospettavo, gli sviluppatori del kernel sono molto lontani da me.
In effetti la " randomizzazione della disposizione dello spazio degli indirizzi " sembra produrre il comportamento che ho osservato sul mio sistema.
Quando ho letto l'articolo di wikipedia, ho capito che lo spazio degli indirizzi è strutturato ogni volta che il kernel parte, ma testandolo ho verificato che in realtà le cose sono leggermente diverse.
GDB ha una bella funzione chiamata " disable-randomization " che è attiva per impostazione predefinita.
Nonostante ciò, libc system (), e credo che qualsiasi funzione di libc, cambi il suo indirizzo ogni volta che avvio GDB.
Scavando più a fondo ho finalmente trovato che la funzionalità del kernel può essere disabilitata a livello del kernel attraverso " / proc / sys / kernel / randomize_va_space ".
Il mio kernel per impostazione predefinita è stato impostato sul valore 2.
Impostandolo a 0, mi sono reso conto che la randomizzazione si interrompe.
Adesso tutto sembra chiaro, ma c'è ancora un pezzo che non va bene.

  • Perché il codice che ho scritto per stampare l'indirizzo del sistema libc, quando lo eseguo dal prompt produce in qualsiasi momento lo stesso indirizzo?
  • È il codice che ho scritto, che non richiede la funzione che lo produce risultato?

Aggiorna
se c'è qualcuno è abbastanza bravo, mi piacerebbe che questo ragazzo mi spiegasse questo:

$ cat /proc/sys/kernel/randomize_va_space
0
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x00843000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00dcd000)
        /lib/ld-linux.so.2 (0x0037b000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00ab7000)
        /lib/ld-linux.so.2 (0x00f14000)
    
risposta data 30.04.2016 - 12:36
fonte

Leggi altre domande sui tag