Re: advanced buffer overflow study

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Apr 2003 20:22:49 +0200 (CEST)
Marco Ivaldi <raptor@0xdeadbeef.info> wrote:


>PS. Mi manca abo8.c, qualcuno ha  idee su come (ed in che condizioni)
>sia possibile exploitarlo? ;)

Ho  condotto  qualche  indagine  su   abo8.c  e  sembra  che  non  sia
exploitabile o almeno  non in maniera standard. Inoltre,  la causa del
segmentation  fault  sembrerebbe nient'altro  che  una violazione  dei
limiti di pagina.  Infatti, dando un'occhiata  al codice  della strcpy 
(preso dalle glibc-2.2.5), si legge questo.

char *
strcpy (dest, src)
     char *dest;
     const char *src;
{
  reg_char c;
  char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
  const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
  size_t n;

  do
    {
      c = *s++;
      s[off] = c;
    }
  while (c != '\0');

  n = s - src;
  (void) CHECK_BOUNDS_HIGH (src + n);
  (void) CHECK_BOUNDS_HIGH (dest + n);

  return dest;
}


Si vede che  la copia avviene tramite quell'offset  off. Da un'analisi
con gdb  risulta che in %ecx  viene memorizzato off mentre  in %eax va
il carattere da copiare (vedi  prima istruzione asm sotto)  e in  %edx 
l'indirizzo src.

Il ciclo per fare la copia è il seguente

0x804cb40 <strcpy+32>:  movzbl (%edx),%eax
0x804cb43 <strcpy+35>:  inc    %edx
0x804cb44 <strcpy+36>:  test   %al,%al
0x804cb46 <strcpy+38>:  mov    %al,(%ecx,%edx,1)
0x804cb49 <strcpy+41>:  jne    0x804cb40 <strcpy+32>

e si vede  che soltanto %edx viene incrementato di 1  per ogni char da
copiare.  Ora  la  cosa che  si  può  facilmente  testare è  che  abo8
restituisce un  segmentation fault quando gli viene  passato un numero
di caratteri in ingresso superiore a un certo valore (dipendente anche
dalle opzioni utilizzate).  Ciò che mi ha permesso  di capire qualcosa
in più è che la strcpy(), superata la  fatidica soglia,  crasha sempre 
sulla stessa istruzione ossia su questa.

s[off] = c;

Ora è evidente  che l'unica operazione critica in  questa istruzione è
valutare l'indirizzo a  cui scrivere c. Ho condotto  qualche test e ho
notato che sulla mia macchina ho sempre questa situazione con stringhe
di "A" di diversa lunghezza (oltre la soglia sopra citata).

0x80aeff8:      0x41414141
(gdb)
0x80aeffc:      0x41414141
(gdb)
0x80af000:      0x00000000

Si vede che all'indirizzo 0x80af000 non viene scritto nulla sebbene in
teoria ciò dovrebbe accadere. Fatti  due conti coi registri al momento
del SIGSEGV, i  conti tornano. Ora, se si  assume una dimensione della
pagina pari a 4KB, si trova  che 0x80af000/4096 = 32943 ossia questo è
il primo byte di una nuova  page frame. Essa non fa parte dell'address
space del processo da cui il SIGSEGV.

IMHO  non è  semplice (o  non è  possibile?) exploitare  questo codice
anche perchè non essendo il buffer inizializzato non esiste neanche la
possibilità di raggiungere .dtors  in quanto il buffer dovrebbe essere
in  .bss.  Inoltre, a  quanto  stavo  notando,  in quella  pagina  non
sembrerebbe   esserci  nulla   di   particolarmente  interessante   da
sovrascrivere (e questo lo conferma anche  il fatto che se si usa come
input una stringa di lunghezza minore anche di un solo byte rispetto a
quella che serve per bypassare i limiti della pagina il programma esce
senza battere ciglio). Forse, se ci fosse qualche altra  variabile e/o
puntatore interessante dietro il buffer, qualcosa la si potrebbe anche
fare ma, in questa situazione, personalmente non vedo soluzioni.

Tutto questo IMHO naturalmente. :)


Alla prossima,

Angelo Dell'Aera 'buffer' 
Emails : <buffer@antifork.org> 
	 <buffer@users.sourceforge.net>

PGP information in e-mail header

Antifork Research, Inc.     
http://www.antifork.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+mYzlpONIzxnBXKIRAr+XAKCgZTiQRj/mcXBXiTbU5RfaqJn2qACgs6PO
rZ3GVFSEhgHIXQcJOnCtcf4=
=1Jnn
-----END PGP SIGNATURE-----

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List