"Smashing The Stack For Fun And Profit" - Rimedi

Question

"Smashing The Stack For Fun And Profit" - Rimedi

#1 da (2 voti)

1

stavo leggendo questo famoso articolo:

Aleph One - Smashing The Stack per divertimento e profitto

e non ho idea di come i canarini dello stack / supporto NX / ASLR possano evitare un attacco del genere. Cercherò di spiegarmi meglio. Strettamente parlando:

stack canaries: valori casuali prima di RET
Supporto NX: nessun flag x per stack (e heap)
ASLR: randomizzazione dello spazio degli indirizzi

Considerando questo esempio:

example3.c:
------------------------------------------------------------------------------
void function(int a, int b, int c) {
   char buffer1[5];
   char buffer2[10];
   int *ret;

   ret = buffer1 + 12;
   (*ret) += 8;
}

void main() {
  int x;

  x = 0;
  function(1,2,3);
  x = 1;
  printf("%d\n",x);
}
------------------------------------------------------------------------------

In questo caso:

I bacini di stack vengono bypassati (cambio solo il valore RET)
Supporto NX: inutile
ASLR: inutile (ignoro l'istruzione x = 1 aggiungendo un offset)

Non capisco come le correzioni di cui sopra possano evitare un esempio del genere.

memory protection

posta Alvin 09.08.2017 - 12:01

fonte

1 risposta

Leggi altre domande sui tag memory protection

Quanto è sicura una macchina virtuale e VPN gratis? [chiuso] Protezione dei dati dopo la perdita o il furto del laptop

score 2 · Answer 1

Il Santo Graal di distruggere lo stack è quello di ottenere il controllo di un puntatore in modo da poterlo puntare al codice malevolo da eseguire. Ci deve essere un overflow nel programma stesso che viene sfruttato. In questo esempio3.c il ritorno può essere facilmente controllato perché è un programma accuratamente predisposto. È una dimostrazione di come superare un buffer vulnerabile per ottenere il controllo di un puntatore, in questo caso il puntatore di ritorno.

In un vero exploit in qualche modo il programma dannoso da eseguire deve essere caricato nella memoria eseguibile e il puntatore dell'istruzione deve essere puntato su di esso.

Le ragioni per cui le protezioni che hai citato causano difficoltà nel mondo reale:

Trova un buffer overflow nel programma, non puoi scriverne uno solo lì dentro. Diciamo di averne trovato uno, ma ci sono canarini in stile Stackguard tra i buffer dello stack e tutti gli altri dati del frame dello stack, come l'indirizzo di ritorno. Trova e scrivi perfettamente i stack canaries quando ne traboccano in modo che siano inalterati, e sperare che l'indirizzo di ritorno non sia stato salvato da nessun altro stile StackShield dal programma che stiamo cercando di ottenere ovunque, e la pila non è stata mescolata. Eroicamente abbiamo un puntatore controllabile.

Siamo riusciti a caricare il programma maligno anche in memoria, dov'è?

ASLR - Progettato per randomizzare l'eseguibile, l'heap gestito da brk (), le immagini della libreria, l'heap gestito da mmap (), lo stack di spazio utente e lo stack di spazio del kernel.

Questo è un peccato, e le librerie di tracciamento e la mappatura della memoria sono difficili ( A meno che tu non sia un artista ), quindi lo otteniamo nello stack o nell'heap, il che è comunque più semplice. Lo otteniamo lì, prendiamo il puntatore su di esso, ma poi Pagine di memoria non eseguibili impediscono l'esecuzione.

Gli exploit return-to-library, come quello che ho linkato sopra, sono stati sviluppati perché le librerie sono necessariamente eseguibili e presenti.